I appreciated the copious power points around to keep the battery charged, and the wireless network I managed to get working today (except in the Civic Suite where the miniconf was, annoyingly [edit: and they've fixed it! Amazing.]). Kudos to the organisers. The tech people from the conference were also fantastic helping me get the projection up and running, even though it was completely my fault it wasn’t working. He was, in fact, a genius full of information, like he said, so people got to see my fairly information-free slides. Thankfully I’d turned up early to make sure it was going to work.

Those slides are available now, as is a written-up version of it that has more content than I was able to fit into the talk. I had to go through it with a hatchet last night and today to make it fit in the twenty-minute slot and some good parts had to go. Honesty dictated that I couldn’t leave out any of the limitations and drawbacks so it was mostly the rest that got the chop. The main talk is on Friday, and there were a few points that came out of the discussion today that I’ll work into it as well. It turns out everything is being webcast live, which I didn’t find out until after I spoke today, but you can watch Friday’s if you like (Renouf 1 feed, 1545L/0245Z). There’ll be recordings up too, apparently later in the week, which’d be an impressive feat, but at some point over the next few weeks or months anyway.

Now I have to try to plan out what I’m going to go to tomorrow. It’s not going to be easy.

The /System/Aliens system incorporates third-party packaging systems into the system, allowing both recipes and packages to depend on components from these alien systems (RubyGems, CPAN, and LuaRocks at this point). Using these features will require building the newest versions of Ruby, Perl, and LuaRocks — if you aren’t using them, you don’t need to do that, and they should be installed automatically when required. Dependencies of the form “LuaRocks:json” are handed off to the alien system to install.

With the final release, these dependencies are now available for use in recipes in the store. Remember to specify compile_version=1.13.0 in any recipe using them. Contributions of new wrappers for other systems are also welcome.

Another important change here is in the default mirror configuration: gobo.calica.com has disappeared, and a new mirror has been added to replace it. If you are using kundor.org you don’t need to make any change, but otherwise you should swap in the new mirror in /System/Settings/Scripts/GetAvailable.conf.

UpdateSettings will prompt you about this change when you install the Scripts package. While the gobolinux.org package mirror is now the master it is not included in the configuration by default. The recipe store remains on gobolinux.org and there is no need to change your settings.

Other than those two important notes, there are also the usual bugfixes and minor feature improvements. There is support for more archive types in Compile (xz and cpio), a bugfix for Cabal recipes, and a few variables should now be correctly set in some more corner cases.

Many of the changes relate to improving functioning with the /System/Index structure that will be in 015, but most work on that is occurring in the “015″ SVN branch. There will be another tools release in the new year (probably another minor version bump) that will incorporate all of those changes and be used in 015. There may also be a 2.10.1/1.13.1 point update early next month to address any issues found in these releases, but not merging the 015 branch.

You will be able to install using `InstallPackage Scripts 2.10.0` when the mirrors sync (assuming you’re not using calica.com), but until then you can use:

InstallPackage http://gobolinux.org/packages/official/Scripts--2.10.0--i686.tar.bz2

and

InstallPackage http://gobolinux.org/packages/official/Compile--1.13.0--i686.tar.bz2

to update. Be sure to merge the changes in GetAvailable.conf when installing Scripts. Please report any bugs you encounter on the bug tracker and ask for help on the lists or the forum.

Thanks to everybody who contributed code, bug reports, and feedback during this release cycle.

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).