© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
73416ba
(Get the code!)
Linking to /usr/local/bin sounds appealling until you do the following rather reasonable sequence of events.
Install 1.8 Gem
Install 1.9 Gem
Uninstall 1.8 Gem.
Result is no link in /usr/local/bin and the user installing gem from source again 'cos those packages don't work properly'.
The choice to install alternatives in /usr/local/bin is precisely so dpkg doesn't have to get involved in the alternatives process and the gem installed ones override the dpkg installed ones - as the user would expect.
However that doesn't get away from the problem of dpkg packages failing to inform gem that they exist so that gem pulls (and compiles!) gems it doesn't really need. That discussion is probably a separate bug.
By default gem always reinstalls even if the gem is up to date, so a simple 'last gem installed wins' solution using alternatives to deal with the /usr/local/bin clash issue is probably the simplest solution that will work.
I will cut some code that implements this solution (including operating the separate gem alternatives system area) and we'll take it from there.