On Friday 03 July 2009 05:24:55 Hisham wrote:
> On Thu, Jul 2, 2009 at 4:51 AM, Michael Homer<mich...@gobolinux.org> wrote:
> > Hi all,
> > Since linux.conf.au[1] falls on my doorstep next year I really don't have
> > any excuse not to go, so I'm considering submitting a paper on GoboLinux.
> > It'd be nice to drum up some exposure around here, and also to expand
> > that "Academic Publications" section on the site.
> >
> > I've talked it over a little with Jonas already. I'm thinking the paper
> > is best written as a collaboration, and then I will do the presentation
> > in January. My concept at this point is a general overview of the system,
> > how it works, and what it helps with, and I'd also like to cover
> > /System/Aliens (which will hopefully be in a tools release by then)
> > because it's just so very cool and unique. That could goose the odds of
> > being accepted too. I'm open to other suggested content as well, but the
> > presentation slot is only 45 minutes.
> >
> > The call for papers[2] closes 5pm July 24 my time[3]. We'd need to get
> > together a title and abstract at least by then, though more always helps.
> > Acceptances should come back some time in September, and the conference
> > itself is 18-24 January next year.
> >
> > As well, anyone who's vaguely in the area and might be interested in
> > making a trip I do encourage. The summer is great, and the conference
> > ought to be interesting too.
> >
> > Let me know what you think.
>
> I think it's an excellent idea!
>
> A while ago I've talked to Lucas about trying to submit something
> abroad (Freenix, perhaps) but we never got around to do it (first
> because we were too involved doing actual work on Gobo, later because
> we were too little involved, I guess...) but I think something like
> this is a great way to get both exposure and some clear goals to the
> project, as well (a number of GoboLinux releases were strongly
> influenced by the FISL deadlines). Count on me to help any way I can.
The abstract is due this coming Friday, though I intend to submit it a few 
days before. Here's a draft(-ish) for that, and also for the paper itself if 
it's accepted. It needs some cleaning up still.

It will need a lot of fleshing out to be the paper, and a lot of trimming down 
to be the abstract (it's about twice as long as it should be for that now), 
but I'd like some feedback that, firstly, I'm on the right track in everything 
I describe there, and secondly on which parts you think should be kept or cut 
for the abstract. I've tried to include at least a mention of everything that 
would appear in the paper, but much of it is either too detailed for or 
probably doesn't belong at all in the abstract.

So please do give that feedback. Include anything you think I've missed out 
too. There is a hacky proof-of-concept patch for LuaRocks integration in 
dependency resolution at http://mwh.geek.nz/files/gobo/aliens-poc.patch - 
against trunk, from a week ago but should still apply.

Background
========
GoboLinux is a distribution using an alternative filesystem hierarchy intended 
to provide a more logical layout for programs and data. Each program is 
installed into its own separate, versioned directory, which also represents 
the package database - “the filesystem is the package manager”. An 
automatically-maintained tree of symbolic links keeps the program contents 
accessible without overhead, while another set of fixed links maintains 
compatibility with the standard FHS.

This set-up has three major implications: firstly, that the origin of any file 
in the system can be found simply by reading the link to discover its location 
– which mkpasswd will give /Programs/Whois/4.7.33/bin/mkpasswd, revealing it 
to be a part of Whois and the version thereof. In fact, any package management 
operation can be performed using only the standard POSIX tools.

Secondly, multiple versions of a program may inherently be maintained in 
parallel. Where the files contained have distinct names, they may be fully 
active, as is the practical case for most libraries (so programs that link 
against specific versioned sonames may continue to do so). Where they do not – 
or at least some of them do not, as with many programs providing executables – 
it is possible both to switch between the versions with a single command and 
to call the executable of another version simply by providing its full path.

Thirdly, it is possible to install programs that are not yet contained within 
the distribution packaging system manually, while still benefiting from all the 
advantages of the package management system. Unlike installing into other 
systems, this does not run the risk of interfering with the default package 
manager nor result in extra “orphan” files strewn across the system – the 
program tree can easily be removed later on in the usual fashion, avoiding the 
complications of maintaining extra programs in /usr/local.

Aliens
======
While installing individual unpackaged programs is very simple in this system, 
installing from other independent systems of package management (such as 
LuaRocks, RubyGems, ...) remains as difficult as in other distributions. The 
individual components may all be packaged up and installed, but the packages 
will inevitably be out-of-date and many will remain unpackaged entirely. These 
third-party package managers are growing more widespread and more popular with 
authors with every passing day, often serving as the only form of publication 
for interpreted-language libraries.

Because of this, users are tempted to install their own trees for these alien 
package systems – either built under /usr/local or worse, allowed to pollute 
the main tree, creating conflicts with the system package manager. Even when 
built in /usr/local integrating this often requires editing files installed by 
the distribution, making the installed package appear corrupt. In either case 
there is no integration between the alien system and that provided by the 
distribution – they are agnostic of each other's existence, and a distribution 
package requiring Ruby-GTK+ cannot have that dependency satisfied by a Ruby 
Gem. This leads users to be forced to choose between their distribution 
manager and the third-party system, to the detriment of both.

The Aliens system was created to bridge this gap. A third-party (“alien”) 
package management system can be incorporated in order to be fully integrated 
with the distribution's package management. This structure should be 
transferable to other distributions, and such transfer is encouraged.

LuaRocks will be used as the example. It will be given full control of the 
tree under /System/Aliens/LuaRocks, to lay out and install software as it 
wishes. The user may manipulate this using the ordinary luarocks command, 
following instructions from the library author's website or elsewhere. The 
distribution's default Lua installation will be configured to include this in 
its ordinary library search (beyond the scope of this paper). This conveys all 
the advantages of a separate install in /usr/local, and does not restrict 
access to the underlying package manager at all – anything the user is 
accustomed to the luarocks command being able to do is still possible.

However, a program within the system package manager may also depend on the 
presence of a Lua library available through LuaRocks. Previously this would 
require re-packaging the alien package for the system's native format, 
expressing the dependency in terms of that, and taking on the overhead of 
keeping the wrapping package up-to-date as new versions are released. Within 
the Aliens system, the program may instead express a dependency in the form of 
“LuaRocks:luajson >= 1.0”, which instructs the system to have LuaRocks ensure 
that the dependency is met.

From the perspective of the distribution package manager, this requires only 
two hooks into the system: one at dependency resolution time, and one for 
installation. These hooks recognise the alien package by the colon in the 
dependency name (separating the name of the third-party system from the 
package within it), and know to dispatch further processing to the Aliens 
subsystem. The subsystem in turn uses a defined protocol to interface with 
wrappers for the third-party system. These wrappers may be either in the form 
of shell scripts wrapping the command-line tools or programs in the languages 
concerned accessing their databases directly.

The entire Aliens subsystem is independent of the overlying distribution 
package manager and should be transferable into any other system, provided the 
hooks into dependency resolution and installation can be provided. It is hoped 
that this may be more widely applicable than just this distribution, and it 
does not depend on any of the filesystem or other changes included in it.

Attachment: signature.asc
Description: This is a digitally signed message part.

_______________________________________________
gobolinux-devel mailing list
gobolinux-devel@lists.gobolinux.org
http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel

Reply via email to