Michael Homer wrote: > I am wondering about that too. "Alien" is a bit too incomprehensible to stand > on its own, but I'm not sure what generic term there is for all of those > package managers as a class. I've used "alien" and "third-party" in the text; > I guess "domain-specific" could cover it too. Perhaps "Aliens: Integrating > domain-specific package managers with distribution package management > systems"? > It's a bit wordy.
"programming-language-specific" is even wordier :-( hmm... > Follows the abstract as I currently intend to submit it - 403 words, > emphasising the novel. Please give any feedback you have (everybody! all of > it!); I will submit it early tomorrow. > This paper describes a mechanism for incorporating the third-party package > managers (such as LuaRocks, RubyGems, CPAN, ...) that have become > increasingly > common into the distribution's package management system. > > These package managers are very convenient for authors, often now the only > obvious means of distribution for interpreted languages. is there anything distinctive about them being interpreted? Haskell (Cabal/Hackage) is usually compiled, and I think some Perl modules have C parts, etc. etc. > However, they do not > integrate with the distribution's package manager at all. 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. There may be conversion scripts. Don Stewart maintains everything on Haskell's Hackage (~1000 packages) for Arch Linux, which are usually almost-up-to-date (a few days) because Arch also uses a rolling-release scheme. (And because the package metadata files were designed to have enough information; some of the domain-specific package management systems are probably worse at various things.) Nevertheless your point is taken that such integration is not quite direct. > 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 and create conflicts with the system package manager. I think $HOME is at least as common. It doesn't allow sharing between users though. All these systems might go out-of-date when the system is upgraded though. Or when you migrate your HOME to a system with different architecture (x86 vs. x86-64 for example) > 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 their 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. and the user who migrates around between distros (including Windows) may long for a familiar, language-specific, interface. > The Aliens system was developed to bridge this gap within GoboLinux, a > distribution with an alternative filesystem hierarchy, but is not tied to any > particular distribution. A third-party (“alien”) package management system > can > be incorporated in order to be fully integrated with the distribution's > package management, with each requiring only a wrapper using a defined > generic > protocol. This structure should be transferable to other distributions, and > such transfer is encouraged. Did we try implementing it? I anticipate unexpected lacks-of-functionality in various alien package managers (though we can probably ask upstream to implement some of the accidentally-missing functionality when it's not too hard) > Each alien package manager, such as LuaRocks, is given full control of a > subtree in the system, here /System/Aliens/LuaRocks. The user may manipulate > this using the ordinary `luarocks` command, following instructions from the > library author's website or elsewhere. However, a program within the system > package manager may also depend on the presence of a Lua library available > through LuaRocks, as part of its ordinary package dependencies. There is no > overhead of repackaging or keeping the wrapped package up-to-date with new > releases. maybe worth mentioning what happens when Lua is upgraded and some Rocks may go out of date / stop working. In Gobo we had the idea of maybe /System/Aliens/LuaRocks-5.1/ or similar. Many other distros are not so friendly to the multiple-versions thing (although Debian sometimes does it e.g. multiple versions of Python, 2.5 and 2.6 etc., though there's only one version of GHC(haskell compiler); and Gentoo has a "slots" system that it uses for a few packages). > The entire Aliens subsystem is independent of the overlying distribution > package manager and should be transferable into any other system, provided > only that a few 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. it is hoped that the idea could be useful. Maybe possible for the concept; details would need to be shaped for each distro's system depending on their particular needs/desires. Anyway, worth exploration, if you/we can write a paper about it... -Isaac _______________________________________________ gobolinux-devel mailing list gobolinux-devel@lists.gobolinux.org http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel
