3 ms·

I am of two minds about package managers after having used Gobolinux for some years. Because once i got familiar with Gobolinux and how it handles things, i ca

I am of two minds about package managers after having used Gobolinux for some years. Because once i got familiar with Gobolinux and how it handles things, i can't shake the feel that most package managers introduce as many problems as they solve. The biggest is that while _nix have sonames to handle multiple lib versions installed at the same time, most package managers balk at there being more than one package of a given name installed at the same time (Debian apparently works around this by including soname-like info in the package names).

tanderson92 10y ago
Exherbo and Gentoo both solve this problem with something called "slots". Namely, you can install various slots of a package, you can depend on a slot, etc. In Exherbo you can tell optionally one package to runtime-depend on the slot of another package that you built it with.
- djsumdog 10y ago
  I love slots. The Gentoo eselect system is way ahead of etc-alternatives or some of the other package select tools I've seen. Slotted binaries are easier though; slotted libraries can get complicated and get into some crazy dependency hell.
  - tanderson92 10y ago
    One of the nice things about Exherbos take on slots is that you won't get breakage with library upgrades because you won't be able to uninstall the old version until all packages declared to build with that ABI (or more specifically that slot was installed and built against) are rebuilt against the new library. ABI breakages are far less painful than on gentoo.
derefr 10y ago
They balk because there's usually only one major version of a package that's still receiving security updates upstream. Thus, a package being able to depend on an old version of another package, is basically morally equivalent to depending on an unmaintained package. Which, if the packge author is gonna do that, they might as well just vendor the dependency. The "version numbers in package names" thing is basically to indicate exceptions to this: cases where there are secondary living packages, with either upstream-tracking or distro-backported security updates. Ideally, there'd be a way to do the same thing just using pure semver heuristics—but any major-version release-stream can just peter out at any time and dependent packages will be none the wiser. So you sort of need your package manager's notion of a package's major-version release streams to be something equivalent to their own "packages" anyway, so that you can have somewhere to put package-alike metadata, e.g. "depending on this is deprecated", when the release-stream for said version gets EOLed upstream.
- digi_owl 10y ago
  This seems to head into "have your cake and eat it" territory. If upstream wants people to stick with the latest and "greatest" then they need to stop breaking APIs and ABIs at the drop of a hat. We do not live in a world where computers encased in concrete at the bottom of the ocean is a sane option for doing computing.
  - derefr 10y ago
    > If upstream wants people to stick with the latest and "greatest" then they need to stop breaking APIs and ABIs at the drop of a hat. "Upstream" usually doesn't care about that. Upstreams—developers who write things that get packaged—almost always have a philosophy of "eh, just vendor it." Which is where things like Docker images come from. Instead, it's the distros that care about being able to update a package's deps out from under it; because this lets them have one copy of e.g. OpenSSL on the system and fix everything that depends on that package, whenever there's a new vuln discovered in it, by just updating that package. They're the ones trying to eat a cake and have it—even as the upstream devs take the view that you should just eat their ingredients directly and never bother baking a cake in the first place. :) --- As a tangent: I'm almost beginning to agree with the Golang philosophy: a "package" is its ABI. New ABI = new package with a separate identifier, that everyone has to explicitly update to. Doing this has two incentive-system effects: 1. It makes package-authors much more reluctant to make breaking changes to their ABIs, which in turn encourages them to think through their ABI before their initial release; 2. The semantics of a semver major version are transferred entirely to the package identifier itself. Almost nobody uses semver major-versions correctly; but if you collapse those semantics up a level, the package-manager can enforce the semantics. So you, as a downstream consumer, can actually be sure there are no breaking ABI changes as long as you're tracking the same package identifier.
- zzzcpan 10y ago
  "They balk because there's usually only one major version of a package that's still receiving security updates upstream." This is not entirely true, because this one version usually can be configured to produce a lot of slightly different versions of that one version. For example, even simply swapping glibc with musl gets you two different versions of the same version of every package. There are a lot more issues though, nix's paper explains some. Package management is a huge mess at this point, docker even managed to capitalize on that.
peterwwillis 10y ago
Package managers are like vehicle transmissions. They are designed a certain way, and if you misuse them, they break. Some are more or less annoying, depending on the perspective of the user and how they use it. Most package managers are some form of automatic transmission. Some provide paddle shifting, some are CVT, some have two clutches and 9 gears, and some just basic four speed boxes of swirling fluid. Almost all of them are a nightmare for a regular person to maintain. That's part of why I use Slackware, which uses Pkgtool. It doesn't track dependencies. It doesn't resolve conflicts. It doesn't roll back changes. It doesn't do much of anything. And it's absolutely wonderful. The only time it ever gets in your way is if you intentionally break it. Of course, i'm on the extreme end of a "power user", but the damn thing is so simple that even a total newbie can grok how it works and the potential for catastrophe if they misuse it (like a manual in a car). Of the ~8 package managers I've used, RPM is the closest to a simple, coherent, complete system. It's still not great, though.

tanderson92 10y ago

Exherbo and Gentoo both solve this problem with something called "slots". Namely, you can install various slots of a package, you can depend on a slot, etc. In Exherbo you can tell optionally one package to runtime-depend on the slot of another package that you built it with.

djsumdog 10y ago
I love slots. The Gentoo eselect system is way ahead of etc-alternatives or some of the other package select tools I've seen. Slotted binaries are easier though; slotted libraries can get complicated and get into some crazy dependency hell.
- tanderson92 10y ago
  One of the nice things about Exherbos take on slots is that you won't get breakage with library upgrades because you won't be able to uninstall the old version until all packages declared to build with that ABI (or more specifically that slot was installed and built against) are rebuilt against the new library. ABI breakages are far less painful than on gentoo.

derefr 10y ago

They balk because there's usually only one major version of a package that's still receiving security updates upstream. Thus, a package being able to depend on an old version of another package, is basically morally equivalent to depending on an unmaintained package. Which, if the packge author is gonna do that, they might as well just vendor the dependency. The "version numbers in package names" thing is basically to indicate exceptions to this: cases where there are secondary living packages, with either upstream-tracking or distro-backported security updates. Ideally, there'd be a way to do the same thing just using pure semver heuristics—but any major-version release-stream can just peter out at any time and dependent packages will be none the wiser. So you sort of need your package manager's notion of a package's major-version release streams to be something equivalent to their own "packages" anyway, so that you can have somewhere to put package-alike metadata, e.g. "depending on this is deprecated", when the release-stream for said version gets EOLed upstream.

digi_owl 10y ago
This seems to head into "have your cake and eat it" territory. If upstream wants people to stick with the latest and "greatest" then they need to stop breaking APIs and ABIs at the drop of a hat. We do not live in a world where computers encased in concrete at the bottom of the ocean is a sane option for doing computing.
- derefr 10y ago
  > If upstream wants people to stick with the latest and "greatest" then they need to stop breaking APIs and ABIs at the drop of a hat. "Upstream" usually doesn't care about that. Upstreams—developers who write things that get packaged—almost always have a philosophy of "eh, just vendor it." Which is where things like Docker images come from. Instead, it's the distros that care about being able to update a package's deps out from under it; because this lets them have one copy of e.g. OpenSSL on the system and fix everything that depends on that package, whenever there's a new vuln discovered in it, by just updating that package. They're the ones trying to eat a cake and have it—even as the upstream devs take the view that you should just eat their ingredients directly and never bother baking a cake in the first place. :) --- As a tangent: I'm almost beginning to agree with the Golang philosophy: a "package" is its ABI. New ABI = new package with a separate identifier, that everyone has to explicitly update to. Doing this has two incentive-system effects: 1. It makes package-authors much more reluctant to make breaking changes to their ABIs, which in turn encourages them to think through their ABI before their initial release; 2. The semantics of a semver major version are transferred entirely to the package identifier itself. Almost nobody uses semver major-versions correctly; but if you collapse those semantics up a level, the package-manager can enforce the semantics. So you, as a downstream consumer, can actually be sure there are no breaking ABI changes as long as you're tracking the same package identifier.
zzzcpan 10y ago
"They balk because there's usually only one major version of a package that's still receiving security updates upstream." This is not entirely true, because this one version usually can be configured to produce a lot of slightly different versions of that one version. For example, even simply swapping glibc with musl gets you two different versions of the same version of every package. There are a lot more issues though, nix's paper explains some. Package management is a huge mess at this point, docker even managed to capitalize on that.

peterwwillis 10y ago

Package managers are like vehicle transmissions. They are designed a certain way, and if you misuse them, they break. Some are more or less annoying, depending on the perspective of the user and how they use it. Most package managers are some form of automatic transmission. Some provide paddle shifting, some are CVT, some have two clutches and 9 gears, and some just basic four speed boxes of swirling fluid. Almost all of them are a nightmare for a regular person to maintain. That's part of why I use Slackware, which uses Pkgtool. It doesn't track dependencies. It doesn't resolve conflicts. It doesn't roll back changes. It doesn't do much of anything. And it's absolutely wonderful. The only time it ever gets in your way is if you intentionally break it. Of course, i'm on the extreme end of a "power user", but the damn thing is so simple that even a total newbie can grok how it works and the potential for catastrophe if they misuse it (like a manual in a car). Of the ~8 package managers I've used, RPM is the closest to a simple, coherent, complete system. It's still not great, though.