Le Fri, Aug 13, 2010 at 05:22:51PM -0700, Russ Allbery a écrit : > > Please remember that setting the system-wide default PATH to support some > applications installed on that system often makes no sense. Timeshare > systems shared by many different people doing many different things are > still quite common, including in batch computing environments. Only the > people who care about a particular piece of software may want their set of > commands to include all those generic commands from some piece of > software.
This is why in my proposition, the path is only changed for the users who are in a unix group of a Debian Blend. It would use a system-wide script, but depends on two manual steps, installing the Blend and adding the user, that can not happen by chance. Also, the change of environment is not to make usable a program that would not be, but simply to make it the default choice or not, under its original upstream name, the one that our users expect, read in the documentation, hear from their colleagues and use in their scripts. There is an obvious selection pressure against file conflicts. The conflicts that we encounter in Debian are the ones that does no make the program problematic on the majority of user's systems outside the Debian world. I think that we already trust our maintainers to not provide a program under its original upstream name if it would causes system-wide side effects to make it a default after changing the PATH. The current approach is to propose to the user to edit the PATH by himself, with one directory per package having a conflict. What I propose is to group these paths per theme (corresponding to Debian Blends), and to set it up automatically only if the user is member of the Blends group. It is mostly an automation of an already existing approach. I completely agree that the best way is to get programs renamed, but it is migrations that can be large and slow, and that may not be accepted upstream when the justification we provide them is to run two programs for which they do not forsee a need to be installed on the same computer. For some conflicts that have a very low probability to happen, it is setting a timeline in terms of years before Debian provides the same ease of use compared to other ways to install the program. [As a side note, I find it funny that you give git as an example, given that they hijacked /usr/bin/git.] PS: my experience of large scientific workstations is that they do not use much binary packages apart for the base system, which is rarely updated. Therefore, the problem we are trying to solve is more for the people whose background is not computer administration, and who are not providing a multi-user, multi-disciplinary resource to their colleagues, but who rather focus on a specific task. Cheers, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100814013241.gj1...@merveille.plessy.net
