[Debian-med-packaging] scripts with language extensions (was: samtools i386-buildable)

[Afif Elghraoui]

On الأربعاء 16 أيلول 2015 05:24, Charles Plessy wrote:
> Le Wed, Sep 16, 2015 at 11:56:32AM +0200, Andreas Tille a écrit :
>> > 
>> > If upstream decides to rewrite a script xyz.pl in Python and will name
>> > it to xyz.py users scripts will be broken as well.
> In 10 years I never saw this happen.
> 

Here is a case where upstream has dropped the language extension
themselves (though not having rewritten the script in another language):
https://github.com/PacificBiosciences/pbalign/blob/master/README.md#pbalign-maps-pacbio-reads-to-reference-sequences


>> > To save our users
>> > from this section 10.4 of the Debian policy was written.  You can not
>> > save users from all bad things that might happen and thus I try to
>> > follow sensible arguments.  These were frequently given and since the
>> > discussion comes up frequently I now assembled a section on the Upstream
>> > Guide wiki page:
>> > 
>> >    https://wiki.debian.org/UpstreamGuide#Language_extensions_in_scripts
> Thanks, this is where it belongs.  But when upstreams beg to disagree with our
> dogma, I think that we should not escalate by making Debian incompatible with
> other platforms.
> 

I agree with Charles about the practicality, but one of the things I
love about Debian is that the policy enforces a consistent system
regardless of the behavior of upstream. I can always expect to find a
manpage for a program (without having to guess whether the program takes
-help, --help, -h, an empty string, or I'm out of luck and it's
undocumented) and to find files in sensible locations by knowing the FHS.

I thought that what I did was a compromise-- I preserved the original
upstream file name as a symlink, but also complied with the policy by
providing the executable without the language extension. I completely
support the principle of no language extension as long as it doesn't
concern the user what language the program's written in (which is
usually the case). It's an unnecessary detail that's better left out. If
the script gets rewritten in another language later, we avoided this
problem by ignoring irrelevant details from the beginning.

As far as unexpected incompatibility---maybe we could explain this in
README.Debian or have it appear upon installation of the package. I'd
like to keep the programs available without the language extension if
possible.

I'll reply to the other point shortly...
Thanks and regards
Afif


-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name