4 ms·
"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 th
by 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.
- derefr 10y agoAh, sure, I'm sort of treating the concept of "package" as being equivalent to "ports-system build formula" here. In pretty much all modern package managers, `pkgmgr install foo` can have any of N prebuilt binary versions of a package like foo-1.0.3 laying around on the package repo server, one of which might be used to satisfy the formula if they match the installation options you passed. The non-BSD-inspired distros, rather than having a separate concept of build artifacts, tend to put the options to match in the "build" part of a package's version string—making them technically separate releases. But it does the same thing in the end. But that's a separate thing from a distro keeping multiple forks of the package itself, with separate release cadences—which mostly only happens as a way to keep individual efforts to create releases from upstream major-versions, or backport to dead upstream major-versions, distinct from one-another.