Le Tue, Jun 19, 2018 at 09:47:27PM +0200, Andreas Tille a écrit : > > Sure. That's why we assembled IMHO good documentation and links that > really sound constructive and helpful[1]. If you think there is room > for enhancement please enhance (or send me patches I'd happily include). > > [1] https://wiki.debian.org/UpstreamGuide#Language_extensions_in_scripts
Hi Andreas, I would not argue that the reasons listed in the wiki are not good, but usually we are arriving too late and in my opinion none of these reasons overcome the trouble caused by being incompatible with the direct users of the upstream software that we package and modify (not to mention that the documentation that we ship may become inconsistent if we do not propagate the modification there...). Regarding providing symlinks, it does not prevent our users to pick the upstream-incompatible command name without being informed in advance. In the end, I do not understand why so much energy is spent changing the last letters of a command, while implementation names seems to be accepted at the beginning at the name. Why "perlfoo" but not "foo.pl" ? Altogether, the upstream guide is good, dropping a note in the upstream mailbox of issue tracker is fine, but for the sake of ourselves and our users, I think that there is no need to change the command names when it is too late. So, do we agree that opotional Lintian overrides are a good compromise ? Have a nice day, -- Charles Plessy Greeting you from Okinawa
