/System/Aliens is a new feature that will debut in the 015 era, helping with the integration of the growing number of third-party package managers into the system as a whole. It’s prompted a few questions lately from those who weren’t around in the dev meetings where it was hashed out, particularly once we decided to submit a paper on it for linux.conf.au next year. It’s a really great feature that deserves explanation, so I’ll try to give an overview here with less technical detail than the paper and more GoboLinux-specific information. I have a working implementation locally, and it will go into trunk as soon as the feature slush for 015 is lifted (hopefully, soon). It should be in a Scripts release shortly after that, and possibly on a CD by January.
The goal of the Aliens system is to pull these various systems under the umbrella of our package manager, so everything within them is automatically available and there’s no need for repackaging. There are a lot of these systems nowadays – as well as the venerable CPAN, RubyGems, LuaRocks, Haskell’s Hackage, and myriad others are in play and growing in popularity. Often those are the only way libraries in their respective languages are published now. I can’t think how many times installation instructions have been “use gem install foo-bar“. Ultimately these systems (mostly) use standardised build and installation systems underneath, so we’ve been able to find the underlying tarball URL and create recipes for them, usually just the standard couple of lines. There’s an overhead in doing that though, and they inevitably get out-of-date. There are ways of automatically importing the entire tree and repackaging them up for the distribution, but they have their own complications and force everything to go through the distribution’s package manager, which can mask useful functionality the alien system provides.
The other temptation for users has been to go entirely over to the third-party system for those libraries, setting up their own tree either in /usr/local (in other distributions), or slightly more cleanly inside a /Programs entry here. Sometimes even over the top of distribution-provided files in /usr, which causes no end of conflicts later on. While at least it’s reversible and mildly clean inside a dedicated /Programs entry, it’s untidy and breaks dependency tracking. If a program depends on Ruby-GTK+, that will have to be wrapped in a distribution package and installed – even if it’s already around via RubyGems, and potentially conflicting with it. Aliens aims to avoid that.
When Aliens is around, alien packages can be installed in their ordinary way, using the familiar gem or luarocks or cabal install … command, and any of the functionality usually provided by those systems can be accessed. All the advantages of a separate tree remain, in this case the entire tree under /System/Aliens/{RubyGems,LuaRocks,Cabal,CPAN,…} being given over to the alien package manager to deal with as it likes, and our standard configurations for those languages being set up to look in there as well. Better though, a dependency from a program in the system package manager can be satisfied via the alien system. If a program depends on Ruby-GTK, it need only declare – within its ordinary dependencies – that it requires “RubyGems:ruby-gtk >= 2.10” and that will be satisfied on installation.
That’s achieved through just a couple of hooks into CheckDependencies and the installation tools. A dependency of the form Foo:Bar is recognised as one on package bar within the alien package manager Foo, and CheckDependencies will hand over to the Aliens subsystem to check that. If the dependency is satisfied, nothing more needs to happen. If not, it will remain in the dependency list and will be installed as soon as it is reached, using the alien package manager.
Each alien system supported will have a simple wrapper layer, using a defined protocol for answering queries and receiving commands. This wrapper protocol is simple and extensible so that adding new supported systems in the future will be easy. Some systems may not support all of the functionality Aliens can make use of – they will simply miss that feature, rather than being fully incompatible. At the simplest, a system need only support checking whether something is installed, and installing it.
Dependencies in the other direction, as from Ruby-GTK+ to GTK+ itself, may be handled one of two ways. Firstly, by defining a mapping of such dependencies as part of the Aliens system: this is not an enormous bother, since it need only be done the once for those items actually depended upon, but it is some. Alternatively, the system dependency may simply be specified before the alien one. If other distributions implemented this system (as we’d hope they might), they might prefer one way or the other of those two. We will probably begin with the second and move towards the first as a simpler migration path.
While I’ve made it sound pretty simple, there are a few technical complexities under the rug that are wrapped up by the Aliens subsystem. From a user level though, they get to rely on the distribution not duplicating or conflicting with their installation, while still having the full range of packages available to them. Users who move between distributions, or to *BSD, Mac OS X, or Windows, may also prefer to have the familiar language-specific interface available to them. If they don’t want to know about it, they won’t ever have to see it or notice it exists. For recipe authors, it’s many fewer dependencies they’ll run across and have to wrap up just to get an application up and running. For the developers (who are also in the first two categories), it’s another world-class feature that makes our lives easier by removing the need for coding so many special cases. For the developers of the packaging systems themselves, Aliens aims to embrace rather than extinguish their works, putting their domain-specific knowledge to work in providing the best way to install software in that language. And for authors of libraries, it lets them publish their creations the way they want, with a functional and consistent installation experience for end-users.
If there’s something I missed or didn’t cover, or you have any questions, comments, suggestions, post a comment, mail the list, or grab me on #gobolinux on Freenode (mwh).