On Sat, Aug 14, 2010 at 10:32:41AM +0900, Charles Plessy wrote:
>
> 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.
IMHO the strongest argument of Russ was that your proposed way to set
the PATH variable in /etc/profile.d just does not work for all shells,
specifically for dash and the frequently used csh clones which are
frequently used in scientific environment.
> 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.
So in principle I like the idea for Blends and we just discussed this
previosely - but there is no *reliable* way to let it work because we
do not really have control about the shell a Blend user is using.
Kind regards
Andreas.
--
http://fam-tille.de
--
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/20100815174857.gf14...@an3as.eu
