Hi Steffen and all, today while talking with a backbox project administrator I discovered that popular tools such as openvas directly calls the amap binary. I never talked with them, but I don't think it is feasible to ask to every security tool provider to patch their code for the only debian benefit. I think I'm then changing again my opinion: the conflict field might be the only proper way to be sure such popular tools (not packaged in debian and some of them not even free) continue to work. Is this one a good reason for a conflict? Thanks for reading, Gianfranco, who really don't want this kind of flame wars in such a beautiful project as debian. |
| Hello, > Gesendet: Sonntag, 06. Juli 2014 um 17:02 Uhr > Von: "Lars Wirzenius" <liw@liw.fi> > An: "Charles Plessy" <plessy@debian.org> > Cc: debian-devel@lists.debian.org, 753704@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 Debian or Ubuntu using colleagues downloading plink (the biological tool) to their home directory and execute that in favour over the spurious p_link we created because of a conflict with putty. This annoys me every day and belittles all the effort we put into our distribution. Conflicting cheers, Steffen |