Packages under the tree

Despite what the title might suggest, and despite there being words to be said about this old pagan festival that was first adopted for purposes of religious domination and later for consumerist purposes, this article is neither about Yule or Christmas (Finnish: Joulu; pronounced Yo-lo[o] or in IPA notation just like written), nor about Christmas presents. It's about software package installation under the *nix directory tree.

The *nix directory hierarchy is a mess. It's not wise to put all your eggs in one basket, and this is how the *nix directory hierarchy is organised. Almost all libraries go in /usr/lib/, their header files in /usr/include/ and so on. It's practically impossible to compile a program against a specific version of a library if the author(s) of that library haven't included the version as part of the name of the library – which is not desirable with minor changes, although it is with major API changes.

It is also not easy to manually remove a package from the hierarchy, as its files are spread all over the place. Yes, package managers do take care of that for packages in the distribution, and apt-get is a wonderful tool. And, yes, stow can be used to manage source packages in /usr/local/. That doesn't change the fact that the hierarchy is a mess with the files of every package interspersed among others'.

A much simpler directory hierarchy is possible. It is called application directories. Now, there are distributions that try to do that. Unfortunately /They Have Been/Corrupted By The/Marketdroid Naming Convention/. What's wrong with simple /usr/pkg/ or /usr/app/? These supposed “idiot users” that need `/Long Names With Spaces And Capital Letters/So That They Can Understand It/` probably use some lame file manager that hides all system directories anyway.

And besides, I want to take it much further. Even GoboLinux has symlinked equivalents of /usr/lib/ and /usr/include/ and so on under /Some/Very/HardToType/Path/. I want to remove these altogether due to the reasons mentioned above. Only the equivalent of /usr/bin/ should remain for reasons of efficiency, and be hard-linked as well for that reason. It should be necessary to explicitly specify the version of a library to compile a program against, instead of having the compiler allot some random version it chooses to find. For example,

        gcc -I/usr/pkg/libfoo-2.0/include \
            -L/usr/pkg/libfoo-2.0/lib -lfoo

or even directly

        gcc -I/usr/pkg/libfoo-2.0/include \
            /usr/pkg/libfoo-2.0/lib/libfoo.so

There can, of course, be a symlink from libfoo-2.0 to libfoo-2.0.123 if 2.0.123 has the “2.0 API”.

While we're at it, I want to remove /usr/ and /usr/local/ and so on as well. You see, it would sometimes be convenient to be able to use packages from multiple distributions simultaneously. So why not install distribution stuff in /debian-sarge/, /debian-etch/, /gentoo-whatever/ and so on, and manually compiled stuff in /local/?

If I, for example, preferred using the stable Debian distribution, but needed some package from unstable, I could simply install those packages from unstable that are needed in the respective hierarchy, and not have worry about them removing the stable versions and eventually having to install everything from unstable. This scheme does, of course, presuppose that the packages in the newer distributions can work with the daemons and so on of a minimal base system (installed in e.g. /sys/) of the preferred distribution.