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.
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