The Aliens idea is really interesting and I was not aware of it previously.
I'm not sure how possible this is with Aliens (and the time available) but another example that might have a more wide ranging scope of interest for the audience could be Eclipse (Eclipse.org) as it incorporates it's own software installation system updating itself and it's own addons. I believe there is a recipe in the recipe database. Regards Rehan -----Original Message----- From: gobolinux-devel-boun...@lists.gobolinux.org [mailto:gobolinux-devel-boun...@lists.gobolinux.org] On Behalf Of Michael Homer Sent: 19 July 2009 06:16 To: gobolinux-devel@lists.gobolinux.org Subject: Re: [gobolinux-devel] Paper for linux.conf.au 2010 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.
_______________________________________________ gobolinux-devel mailing list gobolinux-devel@lists.gobolinux.org http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel
