On Fri, 2020-12-18 at 14:11 +0200, Adrian Bunk wrote: > On Fri, Dec 18, 2020 at 09:11:42AM +0100, Raphael Hertzog wrote: > > On the top of my head: > > - as a user, I like to have to only know about "apt/dpkg" instead > > of pip/npm/gem/... > > This sounds as if you are making the case for a higher level tool > that calls lower level tools like apt and npm.
While there have been several attempts at a universal packaging system (Nix, RPM, Dpkg/apt, pacman...), none have truly come to be the "one true system". Further, simply implementing such a system as an abstraction of several underlying systems would be impossible, from a design perspective. Every packaging system treats installed packages differently. NPM will favor just installing into a local folder: pip has a separate set of installed packages for every python version. Gem permits many versions of the same package to be co-installed: apt would literally explode if you tried that [1]. Almost none of these packaging tools are really intended to install end- user programs. They leave that task up to the distribution. Yes, sure, many of them will try it: but when was the last time you saw an Electron app on the npm registry, or a PyQT app that didn't recommend you install some things separately with apt? Our theoretical system would need to locate such packages and their dependencies, even when such dependencies are on many disparate packaging systems. It would need to manage numerous different views of the list of installed package, some of which are completely inconsistent. Furthermore, look at namespacing. If I call magic-installer imagemagick, do I mean the NPM package, or the apt package? Both? I'm sure you could find an example of a single package name duplicated across all the various managers: imagemagick was just the first to come to mind. And if you say, "well, obviously, every package name would be prefixed with its manager", then why are we even bothering with this exercise, when we could just use the manager? While I do agree that it would be great if things like this could work more smoothly, I have to disagree that the way to do that is through another package manager. The limitations on our current tools are a direct result of their design requirements: I can't see that changing soon. [1]: Trust me: since I tried, I was never able to regrow my eyebrows, and I still find chunks of .deb files all over the house. Thanks for reading, Calum
signature.asc
Description: This is a digitally signed message part
