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
