Hi Loïc, On Thu, Sep 04, 2008 at 04:04:57PM +0200, Loïc Minier wrote: > > Do you mean that only the gem system should be setup to use gem > > installed binaries ? > > No, I mean that it's not a policy violation to try to add the gem > binary path to PATH on a best effort basis because packages will > continue to work whether PATH has the gem binary patch or not. > > I wish manually installed gems benefit the users of the system > (including the admin) and services as much as possible since someone > went through the hassle of installing the gems: it means they either > additional software or newer software available as gems. >
I assume you meant "it means they *want* either additional software or newer software available as gems". Could the following statement be considered a corollary of the above ? Binaries installed by the administrator should take precedence over binaries provided by packages. That's my interpretation of the following line in /etc/environment: PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games" > > B. A daemon that runs gem installed binaries. > > Example: cgi scripts under apache2. > > That one I'm afraid I thought would be covered by /etc/environment, but > I now realized it's not. > > I thought /etc/environment was also sourced by central sysvinit scripts > to affect all child processes, but this is wrong, it is only sourced by > some scripts and used by pam_env for some services. > > I should dig up the rationale for implementing support of > /etc/environment in the way; the OneTruePath spec doesn't hint at this. > > > I'm certainly again overly naive, but it would seem to me that a > central definition of the default environment should cover more than > pam sessions and a handful of init scripts. > Shall we revisit OneTruePath to cover non user-session use cases? I > certainly understand that pam_env made it easy to implement OneTruePath > for cases where the environment needs to be cleared/sanitized (sshd > comes to mind), but it seems to fall short on covering the use case you > describe as B. > Perhaps we can simply enforce this support in init/upstart? > > > However, if there are reasons that we didn't want to support setting > the PATH for *everything* which drove the current implementation of > OneTruePath to only use pam_env and selectively read /etc/environment > from some key places (e.g. gdm, cron) then these reasons probably apply > equally to gems. > In this case, we should pursue with the current style and add support > for /etc/environment in apache2. > I wasn't around when this was discussed so I can't comment on that. > > It seems to me that symlinking gems binaries to /usr/local/bin/ is the > > simplest solution to cover both use case A. and B. > > While it might be simple to build on the current level of support for > the /usr/local/bin path in various places, it seems to be a dangerous > solution, even more when using the alternatives system. > Could you elaborate why using the alternatives system is even more dangerous ? 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/". > 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 ? > 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. 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). In the mean time, what can be done in the Intrepid time frame ? 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. 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. -- Mathias Gug Ubuntu Developer http://www.ubuntu.com -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
