There’s been some related work lately, too.<p>- Nix packages are still archives, but they do have separate roots, and use runpath to hardcode shared library paths into the Nix store.<p>- rpm-ostree provides something of a hybrid between images and packaging, allowing for more seamless OS upgrades while still supporting more or less traditional packages on top.<p>I hope that in the near future, Linux package management can jump into the next phase. Package management on UNIX likes already offered some neat advantages with their complications, but it’s interesting to watch this occur while Windows and macOS largely maintain the same model they’ve had basically forever, for better or worse. (I guess on Windows and macOS there’s an increased focus on an app-store-based distribution model, but it’s not really full system package management. The most interesting bit is probably the sandboxing.)
This is very interesting as this is almost identical to how the Haiku Operating System does package management using their own packaging format (hpkg) which uses packagefs. [0] [1]<p>This format is used more than just to package applications, but to update the whole OS in a consistent manner [2] as it is also versioned in with shared-libraries and this was implemented in 2013.<p>[0] - <a href="https://www.haiku-os.org/blog/zooey/2011-01-08_package_management_first_draft/" rel="nofollow">https://www.haiku-os.org/blog/zooey/2011-01-08_package_manag...</a><p>[1] - <a href="https://www.haiku-os.org/guides/daily-tasks/install-applications/" rel="nofollow">https://www.haiku-os.org/guides/daily-tasks/install-applicat...</a><p>[2] - <a href="https://www.haiku-os.org/blog/bonefish/2011-06-20_package_management_system_package/" rel="nofollow">https://www.haiku-os.org/blog/bonefish/2011-06-20_package_ma...</a>
At work we avoid package manager altogether following the mantra that the best package manager is no package manager at all.<p>All the software is installed in a global directory /cvmfs and distribute to all the clients using FUSE and simple http servers.<p>Then different departments have ownership of different subpaths. General software that can be useful to everybody is installed in /cvmfs/sft.cern.ch software that is useful to only a specific collaboration is installed in, as an example, /cvmfs/lhcb.cern.ch
I don't think that possibly slow package manager is main Debian problem. There are more serious issues:<p>- bug tracker is email-based, not web-based, very old, and without keyword search.<p>- old versions of software<p>- unnesessary duplication: repositories contain Python packages that can be installed with Python package managers.<p>- Debian is not friendly to third-party software, to closed-source software. For example, to install Slack or VS code you have to add third-party repository and give permanent root access to your system to Slack Inc or Microsoft. You have a choice between backdooring your system or not using third-party apps. Compare this to Android that is also linux-based but provides a reliable and comfortable jail for every application except Google's.<p>- Debian doesn't protect your information from malicious software. For example, if you install third-party app, it will be able to read your browser's history and cookies in your home directory. Also, any unprivileged program can read hardware identifiers like MAC address, hardware list, disk serial number, BIOS data etc. This is perfect for tracking users even if they reinstall or change their operating system. Again, compare this to Android.<p>- package manager doesn't allow to install several versions of PHP or Node.JS if you are working on several projects. But for language like Python they allow to install two different versions, why Python gets such a privileged treatment and PHP or Node doesn't I don't understand.<p>There are projects aiming to solve some of these problems like Snapcraft, but as far as I am aware, they are not integrated into Debian yet.<p>Also, it is a bad idea to hardcode paths (like /use/share) within application, so that you have to recompile it to change the path. All applications should be portable by default to make installation into home directory easier.
While I see the advantages and really enjoy this type of work (and the ones like Nix and OS-as-an-image efforts), I don't think it would be a one-true-solution in a one-size-fits-all construction.<p>Sometimes you want a single filesystem, sometimes you want multiple filesystems, sometimes you want an image copied into RAM and nothing more, sometimes you don't have the resources to even load something like FUSE.<p>I believe that if we are to make anything better we have to be able to either switch or combine the many ways one can make a modular or composable system.<p>We can already swap bootloaders, kernels, desktop environments, transplant storage from one system to another and continue working. It should be just a feasible to switch filesystem/package models.
That's super interesting! I've been pondering better package management tools for a while as the current landscape seems stagnated.<p>I hope some ideas from distri will make their way into mainstream distros. Maybe the more agile ones (Gentoo, Arch) would be interested?
A package-specific /ro prefix is annoying and will not persuade many.<p>void linux uses standard paths, and still has a blazingly package manager, without the need for images being mounted ro.
<a href="https://wiki.voidlinux.org/XBPS" rel="nofollow">https://wiki.voidlinux.org/XBPS</a><p>pacman is also pretty fast. apt, nix and rpm/yum are by far the slowest package managers. suse's has the fastest undo, via btrfs snapshots.
This is very nice and it comes as rather surprising to me that it doesn't exist yet in a "serious" Linux distribution.<p>While reading about the file system structure I was reminded a of Gobo Linux concepts - have you heard of it?<p>I would really like to use something like this on my computer. Are there disadvantages serious enough to make pursuing this not worth while?
Interesting, this mirrors a lot of thoughts I've had on package management on Linux.<p>I'm not sure I like the idea of using file system images as packages, wouldn't that have overhead in terms of the sheer number of mount points you'd need, and additionally the permissions needed to actually mount it.<p>Keeping each package separate is a good idea, I certainly think the current 'soup' method of package management is not ideal. By 'soup' I mean adding files all over the place, and then giving it a good stir by running some scripts; it's very difficult to get back to the state the system was in before the package was installed without doing extra work to keep track of those changes.
I was looking through the Alpine package management system, a lot of packages post-install script would add a user, but the remove script rarely removed that user.<p>Ideally packages shouldn't care where they're installed to. If a binary in the package needs to know where it's installed to, it's possible to work that out at run time (even for libraries, although it's not that straight forward).<p>In my idea for a package manager, each package would have different types of files in different directories, e.g. all command line binaries would be in /bin, all libraries in /lib, all fonts in /share/fonts, etc. In addition, it would be possible to have scripts run when another package was installed that provided a set of files you could use, for instance: when a package that contains fonts is installed, the package that is responsible for fonts on the system would add the relevant directory to the config and refresh the cache.<p>If a package had a library in /lib, a package could update /etc/ld.so.conf and refresh the cache. Linking files to shared directories would be avoided as much as possible (you probably need to do it for /bin). Using an exchange directory is somewhat of a crutch, patching the system to work as applications expect a traditional Linux system to work.<p>Hmm, this post seems to have just turned into a bit of a brain dump.
The only thing I want is a distro that lets me download a package from the web and install it locally without connecting to any central repo.<p>I recently learned that Slackware does that, so as soon as I have a little free time, I'll switch to it.
I'm curious about the no-triggers claim. There's stuff that happens after installing packages sometimes, which you can't put into an image. For example refreshing the font cache. How does that work here?
So ... this is more or less exactly how Haiku's package management system works. (It was designed in ~2008-2009, merged into the nightlies in 2013, and of course has been used by default since then.)<p>We use different terminology for a number of these things, but all the concepts are almost identical. Is this really the case of two completely separate creations of the same idea? Or is this another instance of the Linux world NIH'ing something a different project had for a while without even mentioning it?