7 ms·

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 po

by veeti 4y ago

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.

Nursie 4y ago
> 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.
- biorach 4y ago
  Yes, but the difficulty and franken-nature of the resulting system means that it's not for the faint of heart.
  - phkahler 4y ago
    So upgrade the whole thing. It's open source so in most cases that's possible.
    - PlutoIsAPlanet 4y ago
      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.
      - Nursie 4y ago
        Maybe you should, those dependencies may contain vulnerabilities.
      - diffeomorphism 4y ago
        > 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...
        charcircuit 4y ago
        Most updates aren't security updates. Not all vulnerabilities in a library affect all consumers of that library. Distros don't have every library packaged. Distros often are not often willing shipping patched versions of dependencies. Distros often offer out of date versions of libraries.
        diffeomorphism 4y ago
        No. The libraries are not "out of date" but intentionally static. These static foundations are what companies pay lots of extra money for with windows ltsc, red hat, oracle, SuSE etc. > distros don't have every library packaged. Exactly. And for those that are packaged they say "these are the versions we support. If you want to us to do the support work, use these". Again for stuff like windows ltsc that means I install version X now and want this to be supported for the next 5 years. If I instead install a consumer version of windows it means X will be out if support by then and I am expected to have upgraded to X+1, X+2, X+3 during these 5 years. Case in point, Firefox has multiple current versions: 102 ESR and 111. Both get regular updates and neither is "out of date".
- AnIdiotOnTheNet 4y ago
  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 4y ago
    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...
- planede 4y ago
  > 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 4y ago
    You might, you might not! Backports do indeed exist for a reason, I just felt like challenging “can’t”
- Ferret7446 4y ago
  If you automate it and work out the kinks, you basically get flatpak.
phkahler 4y ago
>> 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 4y ago
  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 4y ago
    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 4y ago
      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 4y ago
    Distrobox is an option too.
ninkendo 4y ago
> 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 4y ago
  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 4y ago
    As both a dev and a user, I prefer dynamic linking over static linking. Usually.
the_why_of_y 4y ago
Technically there is such a thing as a standard RPM, as specified by LSB. https://refspecs.linuxfoundation.org/lsb.shtml https://refspecs.linuxfoundation.org/lsb.shtml These are, of course, not distro packages, but ISV packages and most RPM features cannot be used.

by veeti 4y ago

Nursie 4y ago

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

biorach 4y ago
Yes, but the difficulty and franken-nature of the resulting system means that it's not for the faint of heart.
- phkahler 4y ago
  So upgrade the whole thing. It's open source so in most cases that's possible.
  - PlutoIsAPlanet 4y ago
    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.
    - Nursie 4y ago
      Maybe you should, those dependencies may contain vulnerabilities.
    - diffeomorphism 4y ago
      > 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...
      - charcircuit 4y ago
        Most updates aren't security updates. Not all vulnerabilities in a library affect all consumers of that library. Distros don't have every library packaged. Distros often are not often willing shipping patched versions of dependencies. Distros often offer out of date versions of libraries.
        diffeomorphism 4y ago
        No. The libraries are not "out of date" but intentionally static. These static foundations are what companies pay lots of extra money for with windows ltsc, red hat, oracle, SuSE etc. > distros don't have every library packaged. Exactly. And for those that are packaged they say "these are the versions we support. If you want to us to do the support work, use these". Again for stuff like windows ltsc that means I install version X now and want this to be supported for the next 5 years. If I instead install a consumer version of windows it means X will be out if support by then and I am expected to have upgraded to X+1, X+2, X+3 during these 5 years. Case in point, Firefox has multiple current versions: 102 ESR and 111. Both get regular updates and neither is "out of date".
AnIdiotOnTheNet 4y ago
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 4y ago
  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...
planede 4y ago
> 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 4y ago
  You might, you might not! Backports do indeed exist for a reason, I just felt like challenging “can’t”
Ferret7446 4y ago
If you automate it and work out the kinks, you basically get flatpak.

phkahler 4y ago

>> 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 4y ago
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 4y ago
  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 4y ago
    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 4y ago
  Distrobox is an option too.

ninkendo 4y ago

> 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 4y ago
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 4y ago
  As both a dev and a user, I prefer dynamic linking over static linking. Usually.

the_why_of_y 4y ago

Technically there is such a thing as a standard RPM, as specified by LSB. https://refspecs.linuxfoundation.org/lsb.shtml https://refspecs.linuxfoundation.org/lsb.shtml These are, of course, not distro packages, but ISV packages and most RPM features cannot be used.