Re: .py endings or no .py endings for scientific packages
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
Reply to: