[Debian-med-packaging] Bug#503367: plink: file conflict with putty-tools

Charles Plessy plessy at debian.org
Tue Oct 28 16:19:25 UTC 2008


Le Tue, Oct 28, 2008 at 02:48:21PM +0100, Steffen Möller a écrit :
>  a) removing the newly package plink from the archive
>  b) add an exception to Debian policy for the case that the two packages
> in name-conflict are not in the base distribution and the two
> maintainers agree that the conflict in names does not matter enough to
> be concerned
>  c) add an exception to Debian policy when the two packages are of
> different priorities and both are out of base, having optional beating
> extra and the two maintainers agree.
>  d) have the binary install below /usr/lib rather than /usr/bin and
> there is some mechanism to set the path right, which should be executed
> prior to the execution of any script that is executing plink.
> 
> I personally am happy with any of the four alternatives but obviously
> would best like b) or c). With an increasing number of applications in
> Debian I am certain that b) or c) will be needed sooner or later, but d)
> may be another interesting option for many. What do you think?

Hi Steffen,

I think that I would like the Debian Blend distributions (formerly called CDDs)
to manage this smartly in the future. We could have some mechanisms that make
sure that for biologists, plink relates to SNPs, not to SSH. But this is a long
term goal with no implementation plan.

In the short time, we first have to tell Upstream that in the end renaming to
"snplink" was not a good idea :) If we are confident that the user sets of
plink and putty are mutually exclusive, I would not mind a Conflict even if it
is not allowed by the Policy. But how confident are we that we will not get
complains? We will be in a much worse situation if we have to make changes
after our userbase is established.

I personnaly would advocate d) because it can be the basis for a more global
solution later. For instance something like /usr/lib/debian-med/plink ->
/usr/lib/plink/plink, and populating /usr/lib/debian-med/ with our other cases
of namespace pollutors-polluted programs. We could then ask our users to put
/usr/lib/debian-med/ in their paths, so that they do not have to micromanage
such issues.

Lastly, Upstream was very responsive; we probably should discuss again with him.

Have a nice day,

-- 
Charles Plessy
Debian Med packaging team,
Tsurumi, Kanagawa, Japan





More information about the Debian-med-packaging mailing list