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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140708112434.ge10...@falafel.plessy.net
