[gentoo-dev] Files owned by multiple slots

[Sven Schwyn]

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)?

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. This not only fills /usr/bin with  
unnecessary identical wrappers, but has another consequence:

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:

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.
- Some useful gems are neither on Rubyforge nor Github and wouldn't be  
covered.

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.

What do you think?
-sven