I disagree somewhat, but I’ll make a distinction between libraries and directly-executed self-contained packages (e.g. apps, binaries, tools, etc)
I agree with Drew DeVault when it comes to apps, even though I personally prefer to use flatpak as much as possible, and only use a distribution’s package for an app as a last resort
However, I think it’s a mistake for any distribution’s own repository to include library packages that are more “officially” available elsewhere
It is bonkers to me the effort that distributions waste by packaging up libraries from rubygems, npm, pypi, or elsewhere, especially since the distribution’s copy will inevitably take longer to get security fixes than upstream
Not only that, but these distribution copies will be installed globally and can be found by that tooling if it happens to be installed, leading to all sorts of conflicts that new Node.js / Python / Ruby developers trip over time and time again
One can make a reasonable argument to run apps in containers/flatpack if they are unmaintained or closed source, but libraries should absolutely come through the distribution’s update mechanism.
The reality is that while there might be ways to get libraries updated faster otherwise, the vast majority of computers would run totally outdated libraries if there wasn’t an automated update mechanism through the distribution. Yes, it might break some apps from time to time, but that is IMHO a sign of a badly designed and insecure app that you should probably not run that way in the first place (see 1st part).
And your example of NodeJS etc. is actually a good example of a fundamentally broken & insecure dependency system leading to problems developing and also running the software often requiring virtual environments or containers to emulate a system-state exactly like the developer had.
(P.S.: many of the small annoyances one can have with outdated libraries and apps can be avoided by running a rolling release distribution like Arch)
Bundle the needed libraries inside the app package, or otherwise prevent them from being globally visible to other apps, and not make it easy for users to directly install them
Those libraries “inside the app package” would still be versions picked by the distro, and would still “inevitably take longer to get security fixes than upstream” as you put it. In addition it would take more disk space by having multiple copies.
I disagree somewhat, but I’ll make a distinction between libraries and directly-executed self-contained packages (e.g. apps, binaries, tools, etc)
I agree with Drew DeVault when it comes to apps, even though I personally prefer to use
flatpak
as much as possible, and only use a distribution’s package for an app as a last resortHowever, I think it’s a mistake for any distribution’s own repository to include library packages that are more “officially” available elsewhere
It is bonkers to me the effort that distributions waste by packaging up libraries from rubygems, npm, pypi, or elsewhere, especially since the distribution’s copy will inevitably take longer to get security fixes than upstream
Not only that, but these distribution copies will be installed globally and can be found by that tooling if it happens to be installed, leading to all sorts of conflicts that new Node.js / Python / Ruby developers trip over time and time again
Hmm, I think you got it exactly backwards ;)
One can make a reasonable argument to run apps in containers/flatpack if they are unmaintained or closed source, but libraries should absolutely come through the distribution’s update mechanism.
The reality is that while there might be ways to get libraries updated faster otherwise, the vast majority of computers would run totally outdated libraries if there wasn’t an automated update mechanism through the distribution. Yes, it might break some apps from time to time, but that is IMHO a sign of a badly designed and insecure app that you should probably not run that way in the first place (see 1st part).
And your example of NodeJS etc. is actually a good example of a fundamentally broken & insecure dependency system leading to problems developing and also running the software often requiring virtual environments or containers to emulate a system-state exactly like the developer had.
(P.S.: many of the small annoyances one can have with outdated libraries and apps can be avoided by running a rolling release distribution like Arch)
I don’t understand your recommendation. How could the distro package apps if they don’t package the libraries they depend on?
Bundle the needed libraries inside the app package, or otherwise prevent them from being globally visible to other apps, and not make it easy for users to directly install them
Those libraries “inside the app package” would still be versions picked by the distro, and would still “inevitably take longer to get security fixes than upstream” as you put it. In addition it would take more disk space by having multiple copies.
Is there a single benefit to this?