motu-release will revert libgems-ruby to the old state.

[Loïc Minier]

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
 Ubuntu.)


 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
 standard PATH?



 [[
 Not really on topic, but I did hear about people complaining that their
 locally installed python was picked up by packaged "#!/usr/bin/env
 python" scripts.
   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
> /var/lib/gems/alternatives/".

 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
 debian-policy: http://thread.gmane.org/gmane.linux.debian.devel.policy/9669
   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
      installation fail?
    - 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
    settings?

 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
 up.
   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.

-- 
Loïc Minier