[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.). Isaac _______________________________________________ gobolinux-devel mailing list gobolinux-devel@lists.gobolinux.org http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel
