-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Sven Schwyn wrote: > Hi > > This question popped up while discussing how to deal with Ruby gems on > Gentoo in a way that gives the user the freedom to choose Portage, > RubyGems or both for gem management. > > http://bugs.gentoo.org/show_bug.cgi?id=268857 > > Here's what it boils down to: > > If a Ruby gem ebuild is slotted, the executables it writes to /usr/bin > are currently postfixed with a version as Portage does not yet allow a > file to be owned by more than one slot. This is not a good solution, see > below for details. > > Is it feasable to extend Portage to allow a file to be owned by several > slots and remove it only once the last slot is uninstalled (aka: once > the ebuild is completely uninstalled)?
Do we have any guarantees that the file you want to share will be compatible with all gems that will possibly use it? > Here's the background: > > RubyGems (the gem manager) deals with dependencies and concurrent gem > versions. It's not unusual to have the same gem installed in various > versions as other installed gems may require different versions. > > If a Ruby gem contains and installs executables, then those are mere > wrappers to a Ruby runner object. As per default, the wrapper will run > the most up-to-date code. You can, however, tell the wrapper to run a > specific code version (e.g. rake _0.7.3_ --version). > > On Gentoo, slots are used for this and therefore ebuilds for software > written in Ruby should (and do) depend on slotted ebuilds of the gems > they need. > > Unfortunately, Portage doesn't allow slots to share files at this point, > therefore every slot has to install it's own versioned copy of gem > supplied executables. You could split the executable off into its own package to avoid this duplication. On the other hand, these file collisions between different versions of the same gem seem to be an upstream problem; how exactly does RubyGems handle this? > This not only fills /usr/bin with unnecessary > identical wrappers, but has another consequence: Hmm, so you aren't merely claiming compatibility (like I asked about above) but identicalness (is that even a word?). Is that really realistic? > Every mayjor version of Ruby (currently 1.8, 1.9 and enterprise edition) > has it's own set of installed gems and therefore Ruby itself is slotted > and eselect-ruby does the switching. I've written a simple patch for > eselect-ruby which assures that all gem supplied executables are > switched correctly, no matter whether they were installed through > Portage or RubyGems. It will, however, only work, if Portage allows gem > executables to be shared between all slots of the gem. > > And here's why plan B doesn't quite cut it: You didn't mention any plan B. > Why not write a gem2ebuild tool and automatically add *all* gems from > Rubyforge and Github as ebuilds. This is most likely a bad idea, because: > > - External dependencies (e.g. with C libs) must be maintained manually. > - All outdated ebuilds must be kept due to gem dependencies to outdated > versions. I'm sure we can check this before gems are added and we can periodically automatically remove old gems. Everything could also be kept in an overlay so as not to pollute the tree. > - Some useful gems are neither on Rubyforge nor Github and wouldn't be > covered. If we have an automatic converter, then it should be easy to direct it to convert those gems that we are interested in regardless of where such gems are found. > There are currently about 7500 gems on Rubyforge and Github as of now. > Multiplied by the number of versions, you get a shitload of ebuilds to > host and sync. > > RubyGems does a very good job dealing with versions and dependencies, so > it's IMHO a good idea not to delegate this to Portage unless absolutely > necessary. We better find a way for Portage and RubyGems to work hand in > hand. This problem isn't unique to Ruby. Common Lisp, chicken, plt-scheme, Scheme, Haskell and Perl (and many more probably) each have repositories of libraries/applications plus some sort of package manager to install and keep track of them. Is there a general solution? Is it possible to redirect calls to these external package managers to the main package manager through some interface (a bit like pkgkit)? What about eix support? Marijn - -- If you cannot read my mind, then listen to what I say. Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML <http://www.gentoo.org/proj/en/lisp/>, #gentoo-{lisp,ml} on FreeNode -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoIANYACgkQp/VmCx0OL2y6KwCgpcweYSuXMn1+bl8NBuJ6+3Qu 2xgAoKyKix1AcUMkkc2SLjzkDSh4pn1e =Aq03 -----END PGP SIGNATURE-----
