On Tue, 28 Oct 2008, Steffen Möller wrote:
Except that snplink is taken by another program
This is a valid point and should probably be discussed with plink
(and snplink??) authors.
and Debian remains incompatible for scripts shared in the community.
This is not really a valid point. In case plink upstream will change
the name (which might happen) these scripts will be adapted soon. Even
if not and you put such kind of scripts to say /usr/share/local/bin a
ln -s /usr/bin/snplink /usr/local/bin/plink
will easily make those scripts work - putting this in README.Debian
might be cheap.
Even if we find
another name, then it seems likely that another later program would have
that name, just having been checked against the real project names. The
iceweasel-icedove solution has the same problem, in principle.
I fail to see the relation between these two things.
I personally see four alternatives:
a) removing the newly package plink from the archive
That does not sound like an alternative.
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
This does not sound sanely.
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.
This does not sound sanely either.
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.
That's what we usually do when those name conflicts occure.
With an increasing number of applications in
Debian I am certain that b) or c) will be needed sooner or later,
I do not think so. IMHO the Debian maintainer has the duty to teach
upstream about problems. Assume any user has a running distribution X
installed on his machine which also features the famous plink from putty.
Now he wants to install the plink binaries from upstream source and
has not set his PATH correctly. So the user might face problems we
just detected in Debian and could have solved by informing upstream
that there is a name space polution in the Free Software name space
which really should be avoided. So it is really in the interest of
plink upstream and its users to avoid this conflict - and to be honest:
Do you *really* think that there are so many complicated scripts out
there that some sed / perl magic could not solve this quickly?
but d) may be another interesting option for many.
You might like to have a look at the phylip package which contains
a real lot of generic binary names which are all put under
/usr/lib/phylip/bin. I tried to contact upstream about this (and
about the license) several times - but with no success so far.
But at least it works on Debian machines via a /usr/bin/phylip
wrapper.
What do you think?
d) is a solution which is usually choosen in cases like this in
Debian.
Kind regards
Andreas.
--
http://fam-tille.de
