On 7/17/07, Luis Lavena <[EMAIL PROTECTED]> wrote: > On 7/17/07, Isaac Dupree <[EMAIL PROTECTED]> wrote: > > [EMAIL PROTECTED] wrote: > > > On 7/17/07, Michael Homer <[EMAIL PROTECTED]> wrote: > > >> On 7/17/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > >>> A very vague thought: maybe what we need is a way to "talk" to other > > >>> package managers, to have a bridge between our management/dependency > > >>> system, and theirs. Perhaps implemented as a plugin-like system. > > >>> Thinking out loud: > > >>> > > >>> If a dependency in the Dependencies file is named something like: > > >>> RubyGems-rubyqt then it means it will be handled by the RubyGems > > >>> plugin. The plugin script will respond to some minimal set of > > >>> operations such as "is_installed", "install", "remove". Plugins would > > >>> be written for those external managers. There wouldn't be recipes for > > >>> each gem, or for each rock. A dependency like "LuaRocks-luasocket >= > > >>> 2.0" would just call the LuaRocks plugin and the plugin would > > >>> query/install LuaSocket using LuaRocks. We would need standard > > >>> locations for these separate trees; I'm at a blank wrt this > > >>> (/Files/LuaRocks/ would be the cowardly escape). A directory for ROX > > >>> appdirs could fit into this scheme as well. Again, it is all still > > >>> very vague in my head. > > >> That works for me. I like it a lot, in fact. It's flexible and it's > > > > > > Yeah, I feel quite good about it too (and I loved Carlo's suggestion > > > of /System/Aliens/ :) ). > > > > I don't want to lose versioning for them totally. (inventing things) > > Suppose we have /System/Aliens/LuaRocks and I want to try out some new > > "LuaRocks 2.0" reimplementation. Or suppose I want to maintain multiple > > sets of debian packages for different debian versions. Hmm, these > > aren't very compelling examples - maybe it's not necessary. I guess we > > would want to make each subsystem as a whole 'rm -rf'-able anyway, > > deleting all the packages it contained as well as any centralized > > database of them required by the system. > > > > The naming scheme... "RubyGems-rubyqt" would look like any other program > > name, should there be some more distinctive punctuation like > > "RubyGems:rubyqt" (... _is_ that more distinctive?)? Also I think we > > will have to provide partial dependency files when a system package is > > required (e.g. I'm assuming rubyqt requires some version of Qt to be > > installed), since the ruby "gems" system can't know what we call our > > _packages_ even if it knows it requires a file like /usr/include/qt.h > > (or a .so file, etc.). > > > > > > I'm coming late to this thread, but what we are talking about is > repackage another packager (rubygems)... something like Debian, which > makes life too difficult to everyone, even maintainers. > > Will be simpler if you check the documentation of a gem, and see the > requirements there (eg. readme). > > Repackage gems as "programs" of Gobo raises other issues, like loading > path for Rubygems (the require overwrite)... > > I'll prefer stay simple instead. Like I commented a few months back, > set Rubygems to install gems globally (Env GEM_PATH to /Files/Gems or > something) > > if not, we will fall in the maintenance hell that debian packages suffer. > > Just my 2 cents :)
Yes, the whole project of alien packages is to avoid that problem. We don't want to repackage stuff; we're designing a protocol of sorts to make the two managers talk. The plan is to set GEM_PATH to /System/Aliens/RubyGems and to make some scripts that will provide a bridge allowing GoboLinux recipes to request gems to be installed via rubygems when they're dependencies to a application. -- Hisham _______________________________________________ gobolinux-devel mailing list gobolinux-devel@lists.gobolinux.org http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel
