| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA1 |
| 3 |
|
| 4 |
Sven Schwyn wrote: |
| 5 |
> Hi |
| 6 |
> |
| 7 |
> This question popped up while discussing how to deal with Ruby gems on |
| 8 |
> Gentoo in a way that gives the user the freedom to choose Portage, |
| 9 |
> RubyGems or both for gem management. |
| 10 |
> |
| 11 |
> http://bugs.gentoo.org/show_bug.cgi?id=268857 |
| 12 |
> |
| 13 |
> Here's what it boils down to: |
| 14 |
> |
| 15 |
> If a Ruby gem ebuild is slotted, the executables it writes to /usr/bin |
| 16 |
> are currently postfixed with a version as Portage does not yet allow a |
| 17 |
> file to be owned by more than one slot. This is not a good solution, see |
| 18 |
> below for details. |
| 19 |
> |
| 20 |
> Is it feasable to extend Portage to allow a file to be owned by several |
| 21 |
> slots and remove it only once the last slot is uninstalled (aka: once |
| 22 |
> the ebuild is completely uninstalled)? |
| 23 |
|
| 24 |
Do we have any guarantees that the file you want to share will be compatible |
| 25 |
with all gems that will possibly use it? |
| 26 |
|
| 27 |
> Here's the background: |
| 28 |
> |
| 29 |
> RubyGems (the gem manager) deals with dependencies and concurrent gem |
| 30 |
> versions. It's not unusual to have the same gem installed in various |
| 31 |
> versions as other installed gems may require different versions. |
| 32 |
> |
| 33 |
> If a Ruby gem contains and installs executables, then those are mere |
| 34 |
> wrappers to a Ruby runner object. As per default, the wrapper will run |
| 35 |
> the most up-to-date code. You can, however, tell the wrapper to run a |
| 36 |
> specific code version (e.g. rake _0.7.3_ --version). |
| 37 |
> |
| 38 |
> On Gentoo, slots are used for this and therefore ebuilds for software |
| 39 |
> written in Ruby should (and do) depend on slotted ebuilds of the gems |
| 40 |
> they need. |
| 41 |
> |
| 42 |
> Unfortunately, Portage doesn't allow slots to share files at this point, |
| 43 |
> therefore every slot has to install it's own versioned copy of gem |
| 44 |
> supplied executables. |
| 45 |
|
| 46 |
You could split the executable off into its own package to avoid this |
| 47 |
duplication. On the other hand, these file collisions between different versions |
| 48 |
of the same gem seem to be an upstream problem; how exactly does RubyGems handle |
| 49 |
this? |
| 50 |
|
| 51 |
> This not only fills /usr/bin with unnecessary |
| 52 |
> identical wrappers, but has another consequence: |
| 53 |
|
| 54 |
Hmm, so you aren't merely claiming compatibility (like I asked about above) but |
| 55 |
identicalness (is that even a word?). Is that really realistic? |
| 56 |
|
| 57 |
> Every mayjor version of Ruby (currently 1.8, 1.9 and enterprise edition) |
| 58 |
> has it's own set of installed gems and therefore Ruby itself is slotted |
| 59 |
> and eselect-ruby does the switching. I've written a simple patch for |
| 60 |
> eselect-ruby which assures that all gem supplied executables are |
| 61 |
> switched correctly, no matter whether they were installed through |
| 62 |
> Portage or RubyGems. It will, however, only work, if Portage allows gem |
| 63 |
> executables to be shared between all slots of the gem. |
| 64 |
> |
| 65 |
> And here's why plan B doesn't quite cut it: |
| 66 |
|
| 67 |
You didn't mention any plan B. |
| 68 |
|
| 69 |
> Why not write a gem2ebuild tool and automatically add *all* gems from |
| 70 |
> Rubyforge and Github as ebuilds. This is most likely a bad idea, because: |
| 71 |
> |
| 72 |
> - External dependencies (e.g. with C libs) must be maintained manually. |
| 73 |
> - All outdated ebuilds must be kept due to gem dependencies to outdated |
| 74 |
> versions. |
| 75 |
|
| 76 |
I'm sure we can check this before gems are added and we can periodically |
| 77 |
automatically remove old gems. Everything could also be kept in an overlay so as |
| 78 |
not to pollute the tree. |
| 79 |
|
| 80 |
> - Some useful gems are neither on Rubyforge nor Github and wouldn't be |
| 81 |
> covered. |
| 82 |
|
| 83 |
If we have an automatic converter, then it should be easy to direct it to |
| 84 |
convert those gems that we are interested in regardless of where such gems are |
| 85 |
found. |
| 86 |
|
| 87 |
> There are currently about 7500 gems on Rubyforge and Github as of now. |
| 88 |
> Multiplied by the number of versions, you get a shitload of ebuilds to |
| 89 |
> host and sync. |
| 90 |
> |
| 91 |
> RubyGems does a very good job dealing with versions and dependencies, so |
| 92 |
> it's IMHO a good idea not to delegate this to Portage unless absolutely |
| 93 |
> necessary. We better find a way for Portage and RubyGems to work hand in |
| 94 |
> hand. |
| 95 |
|
| 96 |
This problem isn't unique to Ruby. Common Lisp, chicken, plt-scheme, Scheme, |
| 97 |
Haskell and Perl (and many more probably) each have repositories of |
| 98 |
libraries/applications plus some sort of package manager to install and keep |
| 99 |
track of them. Is there a general solution? Is it possible to redirect calls to |
| 100 |
these external package managers to the main package manager through some |
| 101 |
interface (a bit like pkgkit)? What about eix support? |
| 102 |
|
| 103 |
Marijn |
| 104 |
|
| 105 |
|
| 106 |
- -- |
| 107 |
If you cannot read my mind, then listen to what I say. |
| 108 |
|
| 109 |
Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML |
| 110 |
<http://www.gentoo.org/proj/en/lisp/>, #gentoo-{lisp,ml} on FreeNode |
| 111 |
-----BEGIN PGP SIGNATURE----- |
| 112 |
Version: GnuPG v2.0.11 (GNU/Linux) |
| 113 |
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org |
| 114 |
|
| 115 |
iEYEARECAAYFAkoIANYACgkQp/VmCx0OL2y6KwCgpcweYSuXMn1+bl8NBuJ6+3Qu |
| 116 |
2xgAoKyKix1AcUMkkc2SLjzkDSh4pn1e |
| 117 |
=Aq03 |
| 118 |
-----END PGP SIGNATURE----- |
Archives