motu-release will revert libgems-ruby to the old state.
loic.minier at ubuntu.com
Fri Sep 5 12:31:04 BST 2008
On Thu, Sep 04, 2008, Mathias Gug wrote:
> Binaries installed by the administrator should take precedence over
> binaries provided by packages.
Yes, I think this should be the case by default.
If the admin wants his binaries to only take precedence in a
particular use case, he could configure the PATH to list the directory
with these binaries first in the PATH only in this use case.
For instance if he wants to use specific binaries when running the
crontab of a particular user, he could setup the PATH env var in that
crontab to list a custom local path first.
(This makes me think that we should have some kind of Debian/Ubuntu
sysadmin guide for the recommended way to achieve common tasks. If you
search the web for such a guide, you find the sysadmin-guide package in
But now I'm tempted to ask whether the proposed gem system allows
installation of gems in a specific directory which is *not* in the
Not really on topic, but I did hear about people complaining that their
locally installed python was picked up by packaged "#!/usr/bin/env
I can imagine why people would complain in this particular case
because most packaged scripts don't use such a shebang so it would
result in differing behavior between packaged scripts. Also it
certainly would confuse our complex python policy tools.
Nevertheless, it seems hardcoding /usr/bin/python is less useful than
picking python from the PATH.
But shebangs and python shebangs are too large a topic for the gem
support we're discussing here I guess.
> FYI the gem system uses its own alternatives and administrative
> directories. The gem postinstall phase calls update-alternatives with
> "--altdir /usr/local/etc/gems/alternatives/ --admindir
Well, in my experience, alternatives I had never touched were sometimes
broken on upgrades (certainly because of packaging errors). Enforcing
proper use of alternatives in packages came up "recently" again on
So proper usage of alternatives is complex. The new usage of
alternatives by gems adds two levels of complexity:
1) because you will have to mix admin installed data with gem provided
data. This opens up plenty of questions:
- binary foo exists already in /usr/local/bin but a gem wants to
install it, should it be overwritten? if not, should the gem
- when removing gems, do you remove blindly all files the gem
installed or only if unmodified?
- admin removes /usr/local files because he wants to start afresh,
will the system be able to recover?
2) because alternatives managed for gems require gem-specific altdir and
admindir settings: what happens if I want to install a similar
system for PEAR or CPAN modules with different altdir and admindir
My point here is: proper behavior might not be the update-alternatives
one, and alternatives are complex already without the additional
questions that the usage of a tree which can contain user data brings
It also look like you would want to mix multiple alternatives dbs to
manage symlinks in /usr/local/bin for each gem-like use case.
> > I think some admins run things like ./configure (the default usually
> > installs in /usr/local) && make & sudo make install to install random
> > software. This would clash with the current symlinks.
> To paraphrase: the gem system setup by the rubygems package could be
> seen as a self-contained component. Providing symlinks in /usr/local/bin
> would open the door to instability in the gem system because other
> installation methods run by an administrator could overwrite the content
> of binaries installed by the gem system.
> Is this an accurate view of your statement above ?
And vice-versa: you also need to make sure you don't overwrite admin
installed data when installing gems.
> > Ubuntu systems also need to allow similar situations to other
> > parallel distribution/packaging systems (as provided by python tools,
> > perl tools etc.).
> I agree with you. This situation raises an interesting topic that is
> probably worth a discussion during the next UDS.
(This is relevant for the inclusion of the first system managing the
/usr/local hierarchy though; we can't simply allow the first
implementation to be released if we know it prevents others.)
> The same way I agree with the view that gems should be provided as
> packages. But that will take time - all of CPAN modules were not
> packaged overnight. Neither was the Python Package Index nor the PHP
> Extension and Application Repository (PEAR).
Perhaps a nicer alternative would be to build packages locally then
(like DKMS): install some machinery which allows one to create a .deb
installing binaries below /usr/bin in a special deb namespace (packages
would be named gemdeb-<name of gem> to distinguish them easily).
> In the mean time, what can be done in the Intrepid time frame ?
I think it's too late for intrusive changes, and we shouldn't push
anything which can not be easily reverted or upgraded from.
We could sacrifice the availability of gems in the default PATH of all
programs while trying to implement a facility to set this up (to
support B). For now, perhaps you could only consider inserting gems in
/etc/environment's PATH (supporting A).
> It seems that leveraging /usr/local/bin/ is one of the best option.
> You've raised a valid point above. I'd like to put in the balance the
> end user experience: the usage of /usr/local/bin would remove one step
> to the configuration process of rubygems in Ubuntu and get rid of the
> "Where did my gem go?" question.
I think Debian/Ubuntu systems are known for the stability of their
packaging system and high quality packages before being known for the
ease of administration.
Do we prefer offering a quick and dirty solution which will be hard
to move away from but works right now, or do we want to engineer a rock
solid solution while only offering now what we can safely offer?
> IMO what goes into /usr/local/ is the administrator responsibility. It's
> disappointing if they install software in /usr/local that breaks other
> things they've installed in /usr/local/, but it's up to them in the end.
I'm not sure I buy into this argument. By this logic, people could
provide downloadable .debs which install files below /usr/local but
that would be ok because the admin pushes the "dpkg -i" button.
I would rather prefer we keep the /usr/local hierarchy as "unknown
territory" for the tools we provide. Data in there could well have
been installed by matters of gems, we don't know nor do we want to
interfere or maintain that hierarchy.
I wouldn't mind that we provided tools which default to pushing data
into /usr/local if we dont provide any warranty on upgrades, removals,
management of that data. The proposed alternatives system for gems
seems to promise a tool to manage installed gems like dpkg maintains
packaged files, and that crosses the line of the usage of this
hierarchy for me.
More information about the ubuntu-devel