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.