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 -- Ubuntu-motu mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
