[gentoo-dev] Re: Files owned by multiple slots

[Sven Schwyn]

Marijn wrote:
>> 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?

Only executable wrappers are subject to sharing and those are  
generated by RubyGems, not written by an author. Unless RubyGems  
changes it's policy (and I don't see any signs for this), it's safe to  
assume that the wrapper will work for all gem versions.

Marijn wrote:
> 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?

It doesn't have to. The generated code is downwards compatible and  
thus an update will simply overwrite the wrapper. (In most cases, the  
new wrapper code is identical.)

Marijn wrote:
> Hmm, so you aren't merely claiming compatibility (like I asked about
> above) but
> identicalness (is that even a word?). Is that really realistic?

Check the wrappers out: Even executables of different gems have only  
minor differences. Here's an example with rake (make for Ruby) and  
passenger-install-apache2-module (the mod_passenger installer):

> --- /Gentoo/usr/bin/passenger-install-apache2-module	2009-05-06
> 21:45:46 +0200
> +++ /Gentoo/usr/bin/rake	2009-05-06 21:46:01 +0200
> @@ -2,7 +2,7 @@
>  #
>  # This file was generated by RubyGems.
>  #
> -# The application 'passenger' is installed as part of a gem, and
> +# The application 'rake' is installed as part of a gem, and
>  # this file is here to facilitate running it.
>  #
>
> @@ -15,5 +15,5 @@
>    ARGV.shift
>  end
>
> -gem 'passenger', version
> -load 'passenger-install-apache2-module'
> +gem 'rake', version
> +load 'rake'


Marijn wrote:
>> - 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.

Of course this can be done. The question is whether it's worth the  
hassle. After all, executables from gems are the only issue Portage  
has with RubyGems and vice versa that I'm aware of. Btw: It would take  
at least two overlays - the second one for Gentoo Prefix.

One followup about gem2ebuild: AFAIK gems don't track external  
dependencies. (Existing tools such as gem2rpm only convert inter-gem  
dependencies.) Therefore, automatically generated ebuilds are just as  
iffy as installing the gem directly. This can only be prevented if  
someone adds the dependencies either manually or with a template. And  
makes sure, that they are still correct on every release of the gem.  
It takes a lot of manpower to do this.

Marijn wrote:
> 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?

I wouldn't be happy about such a solution. This "assimilation" sounds  
like trouble and the current co-existence works quite well in most  
cases.

-sven