Re: RFC: Policy 10.1 and appropriateness of package conflicts
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
Reply to: