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 :) -- Luis Lavena Multimedia systems - Leaders are made, they are not born. They are made by hard effort, which is the price which all of us must pay to achieve any goal that is worthwhile. Vince Lombardi _______________________________________________ gobolinux-devel mailing list gobolinux-devel@lists.gobolinux.org http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel
