[phkahler]

>> The problem with that model is that it puts the burden on the distro maintainers to package every possible application for their distro.

That's kinda what the distros ARE. Also, if you're debian based and debian packages are not compatible with your distribution you're actively fucking something up for "reasons" - stop doing that.

If an app can't use a standard .deb or .rpm then the distro is doing something wrong. If dependency version management is too hard, someone is doing something wrong - not sure who, could be a library maintainer or an app maintainter. Let's not ship half an OS with every app to avoid this stuff.

[veeti]

Have you ever actually worked on distribution packaging? There is no such thing as a "standard" .deb or .rpm. Unless you're statically linking against distro policy they have dependencies on the particular version of the distribution they are built for.

You can't take a "standard" .rpm from the Fedora repositories and install it on CentOS. You can't take a .deb from Debian 11 and install it on Debian 10.

[phkahler]

>> There is no such thing as a "standard" .deb or .rpm. Unless you're statically linking against distro policy they have dependencies on the particular version of the distribution they are built for.

If you're using a "Debian based" distribution, the "standard" .deb is the one shipping with Debian. If it doesn't work on the derivative distro, they are doing something wrong. Or like I said, maybe the dependencies are doing something wrong.

[PlutoIsAPlanet]

Find a deb packaged for an older version of Debian and see if it runs, there's no guarantee, if the software was closed-source you're basically out of luck, unless people statically link all of glibc, ssl etc into their application which is a big no no.

This is the problem that Flapak, Snap etc try and solve. I won't put AppImage onto that list because it actually doesn't solve the problem it just makes it worse.

[tremon]

So, Flatpak and Snap solve the problem of wanting to run stale software? That ought to be a very niche requirement, I would think.

I was under the impression that Debian already solved that problem by allowing you to deploy an older Debian version in a chroot with debootstrap? As long as the Linux kernel is binary compatible, that should work fine. Although I have to admit I don't use stale software that often, so I have little experience in that area.

[zorr]

They solve the problem of being able to run software against a known set of dependencies instead of depending on the versions that come with the distro. Older packages can still run even when the dependency version the distro provides has changed in a breaking way (as parent suggests), but also the other way, new packages can ship features using newer dependency versions that the distro might not have yet.

[dizhn]

Distrobox is an option too.

[Nursie]

> You can't take a .deb from Debian 11 and install it on Debian 10.

I mean, you can, if you also install its dependencies. And you may end up with a weird franken-system, but you can. You can even automate it and set preferred distros with pinning, it's how people run things like hybrid testing-unstable distros.

[AnIdiotOnTheNet]

That's the point though: this sort of thing is not ridiculous on most OSs. I should be able to use old versions of software (or new ones for that matter) without having to worry about causing my system to catch fire and explode.

[phkahler]

That just requires the ability to have multiple versions of a dll, or to install specific versions with an app, or to statically link. Lots of ways to deal with that, don't distributions support any of those options?

Oh, not all libraries support that. They need to...

[biorach]

Yes, but the difficulty and franken-nature of the resulting system means that it's not for the faint of heart.

[phkahler]

So upgrade the whole thing. It's open source so in most cases that's possible.

[PlutoIsAPlanet]

You're shifting more work onto distros and users that shouldn't be work in the first place, and basically preventing non-linux literate people from using their OS.

If I install software on MacOS or Windows, I don't have to care if it was packaged for an older version etc, or that my distro may not package a dependency.

[diffeomorphism]

> shouldn't be work in the first place.

It seems very much intentional. You could just keep multiple different, vulnerable versions around and keep everything working. Instead distros say "Nope. We support exactly one version. Update or die."

That is also why you have runtimes, grafting, support sunset,... . I agree that a different trade off makes much more sense for desktops. For servers though...

[Nursie]

Maybe you should, those dependencies may contain vulnerabilities.

[planede]

> I mean, you can, if you also install its dependencies.

You will very likely bump into conflicts. Or you you need to upgrade a lot of fundational libraries (like libc), at which point why stay on Debian 10?

Backports exist for a reason.

[Nursie]

You might, you might not!

Backports do indeed exist for a reason, I just felt like challenging “can’t”

[Ferret7446]

If you automate it and work out the kinks, you basically get flatpak.

[the_why_of_y]

Technically there is such a thing as a standard RPM, as specified by LSB.

https://refspecs.linuxfoundation.org/lsb.shtml

These are, of course, not distro packages, but ISV packages and most RPM features cannot be used.

[ninkendo]

> Unless you're statically linking against distro policy they have dependencies on the particular version of the distribution they are built for.

The irony here is that we’re discussing flatpak/snap, which take the idea of static linking to the absolute extreme by doing something closer to a container where every dependency is part of the package. Maybe static linking being “against distro policy” is tossing the baby with the bath water by causing maintainers to reach to a much worse packaging method (snap) because the distro policy is just too obnoxious.

There’s no good reason you couldn’t just statically link (or relocatably copy) your dependencies into your .deb except the distro maintainers being purists. It would make the process of building a deb (or RPM or whatever) trivial because you’re using it as a dumb archive format for your build artifacts, similar to how a container works.

[ranger207]

Static vs dynamic linking is the core of the packaging debate isn't it? Like, distro maintainers say that dynamic linking is better because it lets them swap out libraries underneath the app in case of like security vulnerabilities and stuff. Devs don't like that because inevitably minor version changes break stuff unexpectedly, plus devs prefer to use shiny and new libraries that distros often don't have. Containers were IMO primarily a packaging and deployment solution, and container-style package formats like flatpak and snap are efforts to force distros to use static linking and stop breaking the app's libraries. IMO distro maintainers should realize that their advantages in security aren't as useful as claimed, and their claimed advantages in distro coherence are only relevant to maintainers, not devs and rarely users.

[JohnFen]

As both a dev and a user, I prefer dynamic linking over static linking. Usually.

[zorr]

> That's kinda what the distros ARE

For the base system and libraries, yes. But why should the distro maintainers be burdened with additional work for every possible enduser application out there? If I write a GTK app and want to make it available for Ubuntu/Debian users through official repositories, I need to make sure it gets added to the official package list, and every time I make a new release, someone else somewhere else has to do additional work just to repackage the application so it is available in the repository.

Maybe a far-fetched analogy, but imagine if browser maintainers have to perform additional work every time a new website launches before it is available to its users.

Also, in this system, the application developer has a lot of extra work for making the application run and build against older versions of its dependencies. If I want to make my app available for Ubuntu 22.04 LTS which has libadwaita 1.1, I cannot use any of the new widgets in libadwaita 1.2 (released 6 months ago) or 1.3 (released earlier this month). I can use those widgets but I'll have to write ifdefs and provide fallback behavior/widgets when building/running against these older versions. I will also have to manually track the various distro versions to detect when I can remove the fallbacks from my codebase.

This is what Flatpak is for. Using Flatpak I can target a specific GNOME SDK version and make use of all the new code immediately, without having to write fallbacks. The downside is that when a user downloads my application through Flathub or another Flatpak repository, it might have to download the additional libraries as well, but they will be the correct versions and they won't be downloaded if that SDK is already available due to other Flatpak applications already installed.

Essentially, something like Flatpak is a middle-ground solution that trades of some disk space for the benefit of less work for distro maintainers (so they can focus on core packages) and less work for application developers (that can use more recent dependency versions and don't have to worry about the versions in other distro's)

[JohnFen]

> If I write a GTK app and want to make it available for Ubuntu/Debian users through official repositories, I need to make sure it gets added to the official package list, and every time I make a new release, someone else somewhere else has to do additional work just to repackage the application so it is available in the repository.

Yes, and that's a good thing for a whole bunch of reasons.

If you don't want to leave it up to the distro maintainers, nothing's stopping you from standing up your own repo to distribute your software to a particular distro. It's a one-liner for users to add your repo to their list so they can use their package manager to install and update your software as usual.

> Essentially, something like Flatpak is a middle-ground solution

Yes, I get that it's convenient for maintainers. But it kinda sucks for users (at least for me), which is why I avoid using software packaged that way.

I'll give flatpack this much credit, though -- it's not a nightmare like snaps are.

[wander_homer]

> Yes, I get that it's convenient for maintainers. But it kinda sucks for users (at least for me), which is why I avoid using software packaged that way.

My browser, mail client, rss reader, music player, video player, image viewer, steam, ... all have been working incredibly well as Flatpaks. I also get free sandboxing for all of them, so for example Steam and its games, don't have access to my ssh and gpg keys or documents.

The only applications which don't work that well with Flatpak are things like my IDE or file manager.

[mikae1]

> That's kinda what the distros ARE.

What things are can change, sometimes for the better. Imagine if distros maintainers could spend their time doing something more productive than doing the same work as hundreds of others are doing.

[mulmen]

But if hundreds of distro maintainers don’t do it then millions of users have to do it.

[tapoxi]

No, users don't do it. The application developers do it in their CI pipelines. Application developers should be the ones building and testing the app, not distro maintainers responsible for a dozen other applications.

[moreresearchplz]

Why should a developer of a free and open-source application, provided free of charge and without any guarantees, have any obligations to package and even test their software on random, thirdparty distributions?

If a distro wants to include their application they have every right in the world to do so. So its up to them to do what ever is necessary to enhance their product with the freely available product of the unpaid developer who created it.

[esarbe]

That's the point of flatpaks - you don't.

You build one flatpak and it will work for all distributions.

[prmoustache]

History has shown that application developers are very bad at releasing good deliverable without too much security holes in the packaged libraries or bad practices. And the sandboxing in flatpak is actually meant to protect users from harm done by clueless devs but it fails because devs can actually build non sandboxed flatpaks and they will do it because they don't care

[ranger207]

History has shown that distro maintainers aren't perfect at patching security vulnerabilities either and that sandboxing is useful regardless. It also shows that user want working software and will go through the effort of inventing new package formats like flatpak to work around distro maintainers. Maintainers now have a choice between complaining that everyone else is doing it wrong and eventually becoming irrelevant, or getting with the program and maybe even offering their expertise to accomplish what people want to do

[prmoustache]

Flatpak hasn't been invented by users but by distro maintainers.

[doublepg23]

Why would you use software if you think the dev is too incompetent to package it?

[tremon]

Because I trust that distro maintainers catch the most obvious errors before packaging and releasing the software.

[ninkendo]

Package it for what? There are a lot of distros. Should the dev be packaging it for every one of them? Debian, red hat, suse, arch, other more esoteric ones? Which distro versions? How many years back should they be maintaining the packages?

[curt15]

How often do distribution maintainers actually audit the package source code?

[prmoustache]

I wasn't talking about audit but dependency lifecycle.

[mulmen]

It’s called a distribution. Literally distributing the software. The distro deals with integrating all the packages into a single compatible system. This includes setting options to maintain system compatibility.

Packaging is not required for testing individual applications. That happens at build time and the developer writes the tests. These are not distribution specific.

The separation of concerns is very clear. If a distribution doesn’t package the code then the user is left to build the application themselves. It’s impractical that a developer would build and maintain their own packages for every flavor of every distribution.

[zorr]

The discussion is mostly about what a distribution should contain. I don't think a distribution has to contain all the possible software applications in existence.

Instead, I think distros have to provide the base packages like desktop environments and related software. All configured for compatibility and complying with the distro philosophy.

But third party desktop applications that are not directly related to the desktop environment are a different category. There is an endless amount of them with varying quality and resources. You cannot expect distro maintainers to spend time on all these random applications.

However, if a third party app is not included in a distro, it does not mean users have to build the software by themselves. That is the problem that Flatpak and Snap and others are trying to solve. They provide sets of distro-agnostic libraries that developers can target instead of having to target each distro separately.

This way a developer can only package the app once, distro maintainers don't have to do extra work, and users can install applications without having to manually configure and build them. Everyone is happy.

[mulmen]

That’s a reasonable position but it puts developer and maintainer experience ahead of user experience.

Flatpak and friends are a pain in the ass to use and offer a shitty UX. Having a single point of contact and well understood mechanism for software management is a feature for users.

I don’t expect my distribution to have every software package ever. I do expect it to fulfill my needs. As long as there are applications in the repository that do what I need I am happy.

[matheusmoreira]

No. I trust distribution maintainers a lot more than I trust other developers.

[dizhn]

You can't have distro specific policies using this methodology.

[vinyl7]

Arch Linux would like to have a word

[lapinot]

This. Also void and alpine. Which have simple, no-nonsense package formats. We get it that deb and rpm are a hassle to learn and write, but it's completely a false dichotomy to say snap or flatpak are the only alternative. In fact they push a widely different model of software distribution, one that completely destroys "user unions" which is a crucial aspect of what distributions are.

[vetinari]

> We get it that deb and rpm are a hassle to learn and write,

They solve problems that arch/pacman didn't start even thinking about. Like reliably updating an installation, that wasn't kept in a tight loop with the upstream repo.

> false dichotomy to say snap or flatpak are the only alternative

we are slowly moving into the world of immutable base systems, like fedora silverblue for example. The last thing you want is for a random app package to modify your base system. Separating system and apps is a good thing.

Edit: names

[wootland]

> They solve problems that arch/pacman didn't start even thinking about. Like reliably updating an installation, that wasn't kept in a tight loop with the upstream repo.

So they've decided to degrade the baseline UX because they want to optimize for people who don't keep their system up to date? As someone who has no problem keeping my system fresh, this isn't a use-case I want prioritized in my package manager.

> we are slowly moving into the world of immutable base systems, like fedora silverblue for example. The last thing you want is for a random app package to modify your base system. Separating system and apps is a good thing.

The "last thing I want" is a package manager that's invasive to use, doesn't have the latest software and is slow. Immutable systems can be a nightmare to actually use. Wrote your own software? Copying to /usr/local/bin is no longer an option, hope you like packaging up your one-off tool!

[vetinari]

> So they've decided to degrade the baseline UX because they want to optimize for people who don't keep their system up to date? As someone who has no problem keeping my system fresh, this isn't a use-case I want prioritized in my package manager.

So, they decided that the update path is always defined, from any state to the latest, without having to update the packages in specific order, where some steps needed may disappear. You know, being robust.

If the year of linux desktop has to happen, not borking the system during updates is a requirement. You don't have a problem with daily updates? Congratulation, but your grandma probably has.

> mmutable systems can be a nightmare to actually use. Wrote your own software? Copying to /usr/local/bin is no longer an option, hope you like packaging up your one-off tool!

Immutable system does not prevent writable /usr/local/bin. Your one-off tool has no business messing with /usr/bin or /usr/lib.

Immutable systems are also minimal; they don't care about your additional software, as it is separated from the base system. You can update your software at any pace you want; nightlies if you want. It just cannot touch anything in /usr (with /usr/local being exception).

[wootland]

I actually don't want a package manager tuned for "my grandma" (the white whale of the linux community). I'm a professional dev, Arch perfectly suits my needs where as Flatpak/Snap... cause excruciating pain every time I'm forced to interact with them (something I go out of my way to avoid at this point).

> Immutable system does not prevent writable /usr/local/bin.

I can't speak to the others, but Nix most definitely does not make /usr/local/bin writable. You have to package up your tools to use them.

[mestelan]

silverblue ;-)

[vetinari]

you are right, brainfart ;)

[panick21_]

> That's kinda what the distros ARE.

Yeah but that the worst part of what they ARE and if they didn't have to spend so much time doing that maybe they could do more innovative things.

[KyeRussell]

Ah, a bunch of “you’re holding it wrong”s, completely devoid from reality. This certainly is an argument about Linux.