Thanks, lots of good comments in here. I've tried to incorporate them into the abstract where possible, the rest I've made note of for the full thing if and when (there's only so much room right now...). On Thu, Jul 23, 2009 at 5:41 AM, Isaac Dupree<m...@isaac.cedarswampstudios.org> wrote: > Michael Homer wrote: >> 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. You're right, I wasn't intending to restrict it to that, and Haskell is definitely one of the goals for the system as well. What I was really thinking of there was RubyGems, which have become almost the only way things are released over there now. There's an earlier stage of the same for Python and probably others, and of course CPAN has been that way for Perl for longer than I can remember. It isn't tied to their being interpreted at all, just that that's a class I could use to describe the trend. I'll see if I can think up a better way of phrasing that by tonight, else I'll put it in as-is with that ambiguity. >> 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 Yeah, there's a similar CPAN-wrapping effort for Debian, which will be discussed in the paper as well, if it's accepted. Those have some inherent limitations through the indirection, so I don't think they're the answer, at least not the whole of it. >> 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. This is an excellent point. I've slotted it in there, and also included it in my post on the subject on the GoboLog, which also gives a more detailed and Gobo-specific overview of the system. >> 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) There may be some of that. I've tried to make the absolute requirements as low as possible, and anything additional an optional extra, so the only real requirement is being able to answer "do you have X installed? Install it then". Hopefully they all provide at least that.
Other than those changes, I've added an explicit mention of Hackage to clarify that it isn't restricted to purely interpreted languages, and also inserted the sentence "The Aliens system aims to embrace, rather than extinguish, these third-party systems." at the end of the second paragraph, which I think explains the approach we're taking pretty well. -Michael _______________________________________________ gobolinux-devel mailing list gobolinux-devel@lists.gobolinux.org http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel
