On 7/18/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.). That's a very good question. How is that going to work? Catching it for "gem install rubyqt" probably won't be possible, but something depending on RubyGems:rubyqt (I like that syntax, too) shouldn't fail to compile. We could just list Qt in the dependencies of everything requiring the Ruby bindings, but that's a little messy and seems like unnecessary duplication.
It would also introduce the need to order dependencies for non-meta recipes which I don't like so much from the perspective of trying to resolve a valid order amongst many programs. [Explanatory sidebar: I don't want to have to make Freshen order things as they're listed in the recipe Dependencies, because most of the time it doesn't matter and is arbitrary (alphabetical). If order matters, resolving among multiple programs becomes impossible when one orders Qt before another package and another puts it after, creating a loop. There's no real way to decide which one should be followed.] Maybe a compatibility layer? A file of the format "RubyGems:rubyqt Qt >=3.0, <=4.0" that will make Compile do the right thing? I don't really like that solution, since we can't possibly keep up with every package in every packaging system. To Hisham's post, yes, I think Freshen (and Manager, and any others that crop up) should concern itself with /Programs updates and leave `gem update` to the individual package managers. If the plugins provide a "has-updates" mode it could prompt "There are RubyGems updates available. You may want to run `gem ...` to install them". But that isn't really necessary and it might not be plausible. And I like /System/Aliens. -Michael _______________________________________________ gobolinux-devel mailing list gobolinux-devel@lists.gobolinux.org http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel
