Hello,
Gesendet: Sonntag, 06. Juli 2014 um 17:02 Uhr
Von: Lars Wirzenius l...@liw.fi
An: Charles Plessy ple...@debian.org
Cc: debian-de...@lists.debian.org, 753...@bugs.debian.org
Betreff: Re: Bug#753704: ITP: amap -- Next-generation scanning tool for
pentesters
On Sun, Jul 06, 2014 at 10:49:30PM +0900, Charles Plessy wrote:
Le Sun, Jul 06, 2014 at 10:33:35AM +0200, Andreas Tille a écrit :
On Sat, Jul 05, 2014 at 04:37:16PM +0200, Ralf Treinen wrote:
This violates the Policy's section 10.1, but it is still my
favorite solution for the reason that you explained above.
I don't agree, packages should not be in conflict when it can be
easily avoided by renaming files.
+1
Feel free to rename yourself, but do not forget to remove me from
the uploaders list.
On my side I find these renamings harmful and illogical. The
probability that people want to use both amaps on the same machine
is close to zero, and the probability that users of both amaps will
be annoyed by the rename is close to one. I think that these
renamings are applied dogmatically in a way that makes Debian
inferior. I do not want to participate to this.
I can see, and sympathise, with several sides of this debate of what
to do when two upstream projects choose the same executable name.
However, I do think what Debian's historically been doing (i.e.,
renaming even when upstream doesn't want to rename) is the right thing
to do.
Given projects foo and bar, which both provide an executable called
yoyo, there is no way for everyone to be happy. Both foo's and bar's
users are, presumably, used to calling it yoyo. Third party scripts
will exist that invoke either using the name yoyo. Whichever yoyo
Debian chooses to call by that name, some users will be surprised and
unhappy.
The standards FHS directory layout gives us four locations in which to
put executabes: /bin, /sbin, /usr/bin, /usr/sbin. In theory we could
then have four providers of yoyo, but that would be very confusing.
Even using bin vs sbin is confusing: if you're used to running foo's
yoyo as your normal user, it'll be quite a surprise when you try to
run it as root and get bar's yoyo instead.
We could have the foo and bar packages conflict with each other, and
in some cases that might not be too bad. However, it would be really
unfortunate for long-term quality, in my opinion, if Debian would
start choosing to compromise like that. It may be true that the
intersection of users of foo and bar are really rare, and that nobody
much would suffer if they conflicted, but it sets a bad precedent.
Conflicts in Debian are meant to be used for a specific reason: when
two packages _can't_ be used together (at least not as packaged). If
we use conflicts to resolve the yoyo for foo and bar, it means that we
are willing to change the meaning of conflicts to also be allowed when
we just can't be bothered to make difficult distro level integration
decisions.
Using conflicts doesn't solve the situation for users, anyway. bar's
users will still be surprised by foo's yoyo, when they find it
installed and it doesn't do what they thought it would. Of course,
foo's users are in the same situation, if foo's yoyo gets renamed.
For this reason, I think the best approach is to get at least one of
foo's or bar's upstreams to rename their yoyo. If that can't happen, I
further think it's better for Debian's users if Debian renames at
least one of the yoyo's. Which one gets renamed will depend on
circumstance. The default, historically, has been that the first yoyo
in Debian keeps the name, and newer yoyos will be renamed. However, if
bar is extremly popular, and foo is rarely used, then possibly foo's
yoyo should be renamed. Or we could decide to rename both to avoid
anyone being surprised by the wrong yoyo.
Note that the Debian alternatives system can't be used for this,
unless foo and bar are both basically implementing essentially the
same interface for the same program, but that's rarely the case in
these cases.
Charles, I'm sorry to hear you think this approach is harmful to
Debian and that you don't want to participate in doing them.
This is a very nice summary of Debian's way of avoiding the technical
conflict. And I am in perfect favour of it when the communities of the
two tools do overlap - but here this is not the case. Few in
biocomputational services or research will be performing network
penetration analyses - and if they are, they can just go and exchange
the installed packages for it for a few hours.
Since those scientific tools are now usually called from some workflow
suite or larger externally provided scripts, with likely spurious error
messages, Debian renaming individual binaries will yield uncertainties,
fears and doubt over employing Debian in the community. And that is so
unfortunate. To give an example, I have my mathematical, medical and
botanical but
