I know there are ways to install software outside of aptitude on debian/ubuntu, (add repo, or build, or download binary, or possibly flatpak/snap/etc).
But being able to download *.deb files was one of the nicest aspect of using a debian based distros and now I’m seeing more and more projects include all distros except deb files.
Someone correct me but I vaguely recall that distributing debs is no longer recommended by debian itself?
- Am I wrong, and have I only co-incidentally stumbled on projects that don’t distribute debs?
- I am right and this seems like a mis-step, removing one of the most beginner friendly features that helped propagate debian based distros?
Flamesuit on.
I see a lot of people doing flatpacks now, fwiw.
Only thing I install via deb these days is, like, Discord I think.
Honestly wish we could just not use flatpak/snap/appImage/whatever due to the wasted space. I’d really rather use a binary and reuse my shared libraries 90% of the time. The only exception was docker/snap were handy for things like a quick test for nextcould or home assistant. Then again I run mostly FreeBSD nowadays so I’m probably an old man telling kids to get off my lawn at this point.
Haven’t ever needed them on Arch. Probably never will.
Having built rpms, Deb and pkgbuild; pkgbuild is so much easier
I was scratching my head trying to figure out how I hadn’t run into this problem before but this answers it. Which is to say, I’m green enough to not have realized that just being handed the source code and letting make out of the cage wasn’t the implicit default.
Flatpak do share libraries, thats what gtk and kde platform flatpaks are. Flatpaks are designed around average GUI bound users. So concerns of using a few dozen megs of libraries for their multi-gig electron apps aren’t really relavent.
Flatpak has really brought to light the question of whether its a distro’s, or a developer’s responsibility to create packages. I personally believe it should be the distro. Devs should be making good software, and if they want to provide a package, then great, but I never have an expectation from any dev of more than source + build instructions. Even a precompiled binary is not an expectation, because then you have glibc vs musl vs windows vs *bsd, and debian stable uses an older version thats maybe not compatable, or maybe arch is too new and doesn’t work yet, and it just goes back to the packaging expectation. So packages of any kind directly from a developer is a courtesy. If you want more packages in a distros repo, that they are building and maintaining, then they should be the ones you levy your complaints.
I see flatpacks kinda bad. Try to switch browsers and import data from browser running a flatpack :) #Impossible
Not actually impossible, just requires you know what you are doing. Its a fixable, usability problem for average users.
So how?
I’ve only personally done it from Firefox based ones, but you can just copy the profile directory from one flatpak app into another, then checking permissions depending on if you’ve installed the flatpak as a user or system. Chrome based ones probably have a similar profile/config directory, but I’ve not used one in a while.
Tried to move from Chrome and had to do all stuff manually. Probably it’s cause they isolated env :)
@socphoenix Until you need two versions of Python because… reasons. When building software it also becomes a hassle: You must have the specific dynamically linked environment or your binary is useless. Solutions are either statically linked builds or containers, flatpaks, etc… Containers can cache dependencies as layers to preserve space however. Besides, space is cheap. Sorry for watering your lawn, but it was kind of dry.
In this case, you should have you dev environment setup in a container (or VM) with the correct dependencies
Something that I have ran into is the mono runtime for gaming, it has many complicated dependinces which can easily conflict with the main system. I just ended up making full containers for older mono versions to get old games to work anyways.
Lol the conflicting the dependencies is a fantastic use for them, I just haven’t really run into that from a user perspective
That’s funny, given that Discord is proprietary, and confining it in sandbox would give most benefits.
FYI - although not official, Discord can be installed as a Flatpak [0], albeit with some features missing [1].
Also, I’ve found Webcord [2] a good alternative for my limited use-case. You may want to try it and see if it works for you. Lastly! I see there’s now a GTK4/Go Discord client available [3], I’ll have to give this a try and see how well it works at the moment.
[0] https://flathub.org/apps/com.discordapp.Discord
[1] https://github.com/flathub/com.discordapp.Discord#differences-in-flatpak-version
[2] https://flathub.org/apps/io.github.spacingbat3.webcord
[3] https://flathub.org/apps/xyz.diamondb.gtkcord4