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 understand the need. LuaRocks in particular does versioning by default -- the recommended path for a home-based repository for example, is ~/.luarocks/5.1/. There was just too much suffering in the transition from Lua 5.0 to Lua 5.1; lesson learned. So it would naturally become /System/Aliens/LuaRocks/5.1/. Versioning could be used on an as-needed basis, without having to put versions on things that don't have or need (I believe RubyGems work with multiple versions of Ruby; If a totally new gems tree appeared, it could be installed as /System/Aliens/RubyGems-2/ in the future, but that's unlikely, so no reason to add /System/Aliens/RubyGems/1/ now just because.) > 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 The colon looks good, analog to an URL protocol. Michael wrote: > Isaac wrote: > > 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. Yeah, you brought a very important point. > 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. Sounds like an acceptable compromise. We can't keep up with every package in every packaging system, but we could keep up with the alien packages that are referenced in GoboLinux recipes. If the user installs rubyqt from the command-line using gem directly, then well, hopefully he'll get a good error message telling them to "install qt" and they'll be able to install it using the facilities provided by the system, as it would happen on any other distro. -- Hisham _______________________________________________ gobolinux-devel mailing list gobolinux-devel@lists.gobolinux.org http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel
