3 ms·

Can you explain what you mean by: "the fragility that can happen when the default way to use software in Linux is `sudo apt-get install`"

iknowstuff 3y ago
Every package can do whatever it wants to your system, upgrades fail when surprising config changes occur, and it all hinges on maintainers knowledge of the state of the distro as well as the software they’re packaging
Etheryte 3y ago
This issue is not specific to Linux and anyone who's worked in development should be pretty familiar with it. You get onboarded to project A which requires Node, okay, you install Node. Some time later you get onboarded to project B which requires a different version of Node. Fine, get nvm and jump between different versions of Node. A bit later you're asked to help out on legacy project C, which only works with Python 2, while you also need Python 3 for newer stuff. After that it's only a matter of time until you need something which requires Homebrew and then all the cards are off the table. Etc.
saltcured 3y ago
Yeah, I am wondering the same. Is this referring to some kind of versioning conflict (like the old Windows DLL Hell)? Does that regularly happen in any Linux distribution repository? Or is this a matter of people going cowboy and mixing in other random repositories on top of the distro? I see the whole role of the distribution maintainers being to provide a self-consistent repository that doesn't have this kind of problem. And as a long-time Fedora user, I don't think I've seen such conflicts with the moral equivalent yum/dnf command. But, I am somewhat rigid about not adding third party repos or RPMs to my systems. The only two exceptions I've come to accept are repos from rpmfusion.org and postgresql.org. While I have certainly seen some bugs in Fedora over the decades, I don't see how some "atomic" solution helps here unless it means reorganizing the community QA resources to test some "minor releases" which batch together a set of package updates, versus trying to support continuous integration where each package can update individually. That would actually worry me though, as my own career experiences cause me to prefer continuous-integration approaches like the traditional Fedora distribution.
- bravetraveler 3y ago
  > But, I am somewhat rigid about not adding third party repos or RPMs to my systems. This is the reason why packages seem so stable, you're deliberately staying within a well-tested ecosystem. Fedora release upgrades probably go well for you also! Packages themselves are a perfectly fine distribution method [under the same guidance]. Once you start mixing packaging spec guidelines; packages of varying quality, you end up wanting compartmentalization like containers/bubblewrap Off the cuff example: Fedora makes heavy use of macros in their RPM specs. Most third party packages don't.

iknowstuff 3y ago

Every package can do whatever it wants to your system, upgrades fail when surprising config changes occur, and it all hinges on maintainers knowledge of the state of the distro as well as the software they’re packaging

Etheryte 3y ago

This issue is not specific to Linux and anyone who's worked in development should be pretty familiar with it. You get onboarded to project A which requires Node, okay, you install Node. Some time later you get onboarded to project B which requires a different version of Node. Fine, get nvm and jump between different versions of Node. A bit later you're asked to help out on legacy project C, which only works with Python 2, while you also need Python 3 for newer stuff. After that it's only a matter of time until you need something which requires Homebrew and then all the cards are off the table. Etc.

saltcured 3y ago

Yeah, I am wondering the same. Is this referring to some kind of versioning conflict (like the old Windows DLL Hell)? Does that regularly happen in any Linux distribution repository? Or is this a matter of people going cowboy and mixing in other random repositories on top of the distro? I see the whole role of the distribution maintainers being to provide a self-consistent repository that doesn't have this kind of problem. And as a long-time Fedora user, I don't think I've seen such conflicts with the moral equivalent yum/dnf command. But, I am somewhat rigid about not adding third party repos or RPMs to my systems. The only two exceptions I've come to accept are repos from rpmfusion.org and postgresql.org. While I have certainly seen some bugs in Fedora over the decades, I don't see how some "atomic" solution helps here unless it means reorganizing the community QA resources to test some "minor releases" which batch together a set of package updates, versus trying to support continuous integration where each package can update individually. That would actually worry me though, as my own career experiences cause me to prefer continuous-integration approaches like the traditional Fedora distribution.

bravetraveler 3y ago
> But, I am somewhat rigid about not adding third party repos or RPMs to my systems. This is the reason why packages seem so stable, you're deliberately staying within a well-tested ecosystem. Fedora release upgrades probably go well for you also! Packages themselves are a perfectly fine distribution method [under the same guidance]. Once you start mixing packaging spec guidelines; packages of varying quality, you end up wanting compartmentalization like containers/bubblewrap Off the cuff example: Fedora makes heavy use of macros in their RPM specs. Most third party packages don't.