Re: Bug#753704: ITP: amap -- Next-generation scanning tool for pentesters
Hi Lars,
thanks for your well-argumented and detailed position on this subject. The
problems that you describe can be roughly summarised by “principle of least
surprise” and “slippery slope”. In this particular case, I quite disagree with
the first, but of course can not entirely dismiss the second.
Le Sun, Jul 06, 2014 at 04:02:05PM +0100, Lars Wirzenius a écrit :
>
> 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.
Here, both programs have narrow and non-overlaping user bases, and are
not installed on fresh standard Debian systems.
This said, you made a good point that one has to consider if programs can be
accidentally called with root priviledges, and what will happen in that case.
I think that it would be a good element for a checklist, rather than a good
reason to forbid any name conflict at all.
We also have to consider that large multi-user, multi-purpose systems are
becoming rare because it is easier to have virtual servers, chroots, and other
container solutions. To the practical possibility of needing both programs at
the same time is even lower than when the Policy was written.
Here the surprise would come only if there were a system that is set up for
both the purpose of bioinformatics and security port scanning, without the
users being aware that there can be one or the other alternative installed. I
think that it is very unlikely.
> 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.
Indeed, we should avoid situations where taking bad technical decisions in the
short term is way easier than solving problems in the long term, and our
draconian policy is efficient for that goal.
However, I think that it is efficient to the point of being too strict (zero
tolerance). We now have frequent rebuilds and other quality controls that
were not available when the Policy was written, and it I think that if we were
on a slippy slope, we would see an accumulation of increasingly worrying cases,
and there would be enough time to implement stricter rules.
Lastly, one of the reasons I take a non-cooperative standpoint here is that the
debian-devel mailing list tends to be the place where some developers call veto
on the choices other developers, and this done too cheaply on my opinion. So
for renamings that will annoy users for sure and solve problems that are only
hypothethical, the question will be “who did it ?”. And I think that those who
call for these renamings should do them themselves and stand at the front for
the possibility of receiving rotten tomatoes from our users. If they are
willing to do this, that would convince me that they are not just talking. On
my side, while I can not be convinced to rename programs in a situation like
this one, I will not block people doing it.
Have a nice day,
--
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan
Reply to: