Bug#683495: Mandating use of /usr/bin/perl in Policy

[Dominique Dumont]

On Saturday, 14 October 2017 11:49:59 CET Sean Whitton wrote:
> I am seeking seconds for the following patch to close this bug, which I
> think is uncontroversial at this point.
> 
> > @@ -185,7 +185,7 @@ All command scripts, including the package maintainer
> > scripts inside the package and used by ``dpkg``, should have a ``#!``
> > line naming the shell to be used to interpret them.
> > 
> > -In the case of Perl scripts this should be ``#!/usr/bin/perl``.
> > +In the case of Perl scripts this must be ``#!/usr/bin/perl``.
> > 
> > When scripts are installed into a directory in the system PATH, the
> > script name should not include an extension such as ``.sh`` or ``.pl``

Seconded

-- 
 https://github.com/dod38fr/   -o- http://search.cpan.org/~ddumont/
http://ddumont.wordpress.com/  -o-   irc: dod at irc.debian.org

signature.asc
Description: This is a digitally signed message part.

Bug#683495: Mandating use of /usr/bin/perl in Policy

[Jonathan Nieder]

Bill Allombert wrote:
> On Mon, Nov 27, 2017 at 09:10:12PM +0100, Bill Allombert wrote:
>> On Mon, Nov 27, 2017 at 11:34:15AM -0600, Gunnar Wolf wrote:
>>> Sean Whitton dijo [Sat, Oct 14, 2017 at 11:49:59AM -0700]:

 I am seeking seconds for the following patch to close this bug, which I
 think is uncontroversial at this point.

> @@ -185,7 +185,7 @@ All command scripts, including the package maintainer 
> scripts inside the
>  package and used by ``dpkg``, should have a ``#!`` line naming the shell
>  to be used to interpret them.
>
> -In the case of Perl scripts this should be ``#!/usr/bin/perl``.
> +In the case of Perl scripts this must be ``#!/usr/bin/perl``.
>
>  When scripts are installed into a directory in the system PATH, the
>  script name should not include an extension such as ``.sh`` or ``.pl``
>>>
>>> Seconded.
>>
>> Before we make it a must, is there a lintian test for it ?
>> How may packages need to be fixed ?
>
> Given Russ answer about the lintian test and result, I second this
> proposal.

Seconded as well. Thanks!

Jonathan

Bug#683495: Mandating use of /usr/bin/perl in Policy

[Bill Allombert]

On Mon, Nov 27, 2017 at 09:10:12PM +0100, Bill Allombert wrote:
> On Mon, Nov 27, 2017 at 11:34:15AM -0600, Gunnar Wolf wrote:
> > Sean Whitton dijo [Sat, Oct 14, 2017 at 11:49:59AM -0700]:
> > > I am seeking seconds for the following patch to close this bug, which I
> > > think is uncontroversial at this point.
> > > 
> > > > @@ -185,7 +185,7 @@ All command scripts, including the package 
> > > > maintainer scripts inside the
> > > >  package and used by ``dpkg``, should have a ``#!`` line naming the 
> > > > shell
> > > >  to be used to interpret them.
> > > >
> > > > -In the case of Perl scripts this should be ``#!/usr/bin/perl``.
> > > > +In the case of Perl scripts this must be ``#!/usr/bin/perl``.
> > > >
> > > >  When scripts are installed into a directory in the system PATH, the
> > > >  script name should not include an extension such as ``.sh`` or ``.pl``
> > 
> > Seconded.
> 
> Before we make it a must, is there a lintian test for it ?
> How may packages need to be fixed ?

Given Russ answer about the lintian test and result, I second this
proposal.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 


signature.asc
Description: Digital signature

Bug#683495: Mandating use of /usr/bin/perl in Policy

[Russ Allbery]

Bill Allombert  writes:

> Before we make it a must, is there a lintian test for it ?

There is -- wrong-path-for-interpreter will pick it up.  The only allowed
path for Perl is /usr/bin/perl; any other path will already be producing
Lintian warnings.

> How may packages need to be fixed ?

https://lintian.debian.org/tags/wrong-path-for-interpreter.html says none.
The one hit there is for a module shipped with Perl that is doing
something weird with #! in a file that isn't an executable.

-- 
Russ Allbery (r...@debian.org)   

Bug#683495: Mandating use of /usr/bin/perl in Policy

[Bill Allombert]

On Mon, Nov 27, 2017 at 02:08:37PM -0700, Sean Whitton wrote:
> Hello Bill,
> 
> On Mon, Nov 27 2017, Bill Allombert wrote:
> 
> > Before we make it a must, is there a lintian test for it ?
> 
> I am not sure.
> 
> > How may packages need to be fixed ?
> 
> I don't think we need to worry about this because it is already a 'must'
> in the Perl policy, and it has been for some time.

It depends what you want to achieve. In my experience, a lintian test is 
much more effective than a policy change to get package fixed.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#683495: Mandating use of /usr/bin/perl in Policy

[Damyan Ivanov]

-=| Bill Allombert, 27.11.2017 21:10:12 +0100 |=-
> Before we make it a must, is there a lintian test for it ?

(Disclaimer: I am not an expert on lintian internals.)

I looked at lintian's collection/scripts file (lines 39-66) and there 
doesn't seem to be such a check.

The lines above serve to collect data about the script, and everything 
after the interpreter is removed.

Later (checks/scripts.pm, lines 314-316) /usr/bin/env is considered as 
an allowed way to avoid specifying absolute path to the interpreter.

A proper check would need to first collect the parameters of the 
interpreter (collection/scripts) and later see if /usr/bin/env has 
'perl' as argument (check/scripts.pm).


-- dam

Bug#683495: Mandating use of /usr/bin/perl in Policy

[Sean Whitton]

Hello Bill,

On Mon, Nov 27 2017, Bill Allombert wrote:

> Before we make it a must, is there a lintian test for it ?

I am not sure.

> How may packages need to be fixed ?

I don't think we need to worry about this because it is already a 'must'
in the Perl policy, and it has been for some time.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#683495: Mandating use of /usr/bin/perl in Policy

[Bill Allombert]

On Mon, Nov 27, 2017 at 11:34:15AM -0600, Gunnar Wolf wrote:
> Sean Whitton dijo [Sat, Oct 14, 2017 at 11:49:59AM -0700]:
> > I am seeking seconds for the following patch to close this bug, which I
> > think is uncontroversial at this point.
> > 
> > > @@ -185,7 +185,7 @@ All command scripts, including the package maintainer 
> > > scripts inside the
> > >  package and used by ``dpkg``, should have a ``#!`` line naming the shell
> > >  to be used to interpret them.
> > >
> > > -In the case of Perl scripts this should be ``#!/usr/bin/perl``.
> > > +In the case of Perl scripts this must be ``#!/usr/bin/perl``.
> > >
> > >  When scripts are installed into a directory in the system PATH, the
> > >  script name should not include an extension such as ``.sh`` or ``.pl``
> 
> Seconded.

Before we make it a must, is there a lintian test for it ?
How may packages need to be fixed ?

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#683495: Mandating use of /usr/bin/perl in Policy

[Gunnar Wolf]

Sean Whitton dijo [Sat, Oct 14, 2017 at 11:49:59AM -0700]:
> I am seeking seconds for the following patch to close this bug, which I
> think is uncontroversial at this point.
> 
> > @@ -185,7 +185,7 @@ All command scripts, including the package maintainer 
> > scripts inside the
> >  package and used by ``dpkg``, should have a ``#!`` line naming the shell
> >  to be used to interpret them.
> >
> > -In the case of Perl scripts this should be ``#!/usr/bin/perl``.
> > +In the case of Perl scripts this must be ``#!/usr/bin/perl``.
> >
> >  When scripts are installed into a directory in the system PATH, the
> >  script name should not include an extension such as ``.sh`` or ``.pl``

Seconded.




signature.asc
Description: PGP signature

Bug#683495: Mandating use of /usr/bin/perl in Policy

[Salvatore Bonaccorso]

Hi Sean,

On Sat, Oct 14, 2017 at 11:49:59AM -0700, Sean Whitton wrote:
> control: tag -1 +patch
> 
> Hello,
> 
> I am seeking seconds for the following patch to close this bug, which I
> think is uncontroversial at this point.
> 
> > @@ -185,7 +185,7 @@ All command scripts, including the package maintainer 
> > scripts inside the
> >  package and used by ``dpkg``, should have a ``#!`` line naming the shell
> >  to be used to interpret them.
> >
> > -In the case of Perl scripts this should be ``#!/usr/bin/perl``.
> > +In the case of Perl scripts this must be ``#!/usr/bin/perl``.
> >
> >  When scripts are installed into a directory in the system PATH, the
> >  script name should not include an extension such as ``.sh`` or ``.pl``
> 
> ~

Seconded.

Regards,
Salvatore


signature.asc
Description: PGP signature

Bug#683495: Mandating use of /usr/bin/perl in Policy

[Dominic Hargreaves]

On Sat, Oct 14, 2017 at 11:49:59AM -0700, Sean Whitton wrote:
> control: tag -1 +patch
> 
> Hello,
> 
> I am seeking seconds for the following patch to close this bug, which I
> think is uncontroversial at this point.
> 
> > @@ -185,7 +185,7 @@ All command scripts, including the package maintainer 
> > scripts inside the
> >  package and used by ``dpkg``, should have a ``#!`` line naming the shell
> >  to be used to interpret them.
> >
> > -In the case of Perl scripts this should be ``#!/usr/bin/perl``.
> > +In the case of Perl scripts this must be ``#!/usr/bin/perl``.
> >
> >  When scripts are installed into a directory in the system PATH, the
> >  script name should not include an extension such as ``.sh`` or ``.pl``
> 
> ~

Seconded.

> As has been pointed out by Gian, there is a broader issue of whether it
> is right for Policy to say
> 
> Perl programs and modules should follow the current Perl policy.
> 
> or
> 
> Perl programs and modules must follow the current Perl policy.
> 
> I think this is actually quite tricky: if packages must follow the Perl
> policy, does that erase the difference between 'should' and 'must'
> requirements in the Perl policy?
> 
> If someone thinks it is a big deal that Policy says only that packages
> should follow the Perl policy, and is willing to do the work to handle
> these complexities, they should file a new bug against Policy.
> Otherwise, let's put that broader issue aside and just fix this
> confusing inconsistency about shebangs.

Logically speaking, since the Perl policy is a part of policy (at least,
it is shipped in the same package and has the same update policies applied
to it), it must be followed by all packages dealing with Perl. It seems
that all that's really required here is an informational pointer that 
there is relevant information to be found in this separate document.

However, if the statement above is kept, it should be changed to 'must'.

Probably in 2001 when this statement, and the perl policy itself, was
added to the policy package, many packages did not meet the perl policy,
so this statement, with the 'should' wording, was needed to weaken
the relationship, as a transitional arrangement. After 15 years, I think
we can safely remove this.

The same wording appears in relation to the menu policy, and though
I haven't looked into it, the same reasoning might apply there.

Cheers,
Dominic.

Bug#683495: Mandating use of /usr/bin/perl in Policy

[Sean Whitton]

control: tag -1 +patch

Hello,

I am seeking seconds for the following patch to close this bug, which I
think is uncontroversial at this point.

> @@ -185,7 +185,7 @@ All command scripts, including the package maintainer 
> scripts inside the
>  package and used by ``dpkg``, should have a ``#!`` line naming the shell
>  to be used to interpret them.
>
> -In the case of Perl scripts this should be ``#!/usr/bin/perl``.
> +In the case of Perl scripts this must be ``#!/usr/bin/perl``.
>
>  When scripts are installed into a directory in the system PATH, the
>  script name should not include an extension such as ``.sh`` or ``.pl``

~

As has been pointed out by Gian, there is a broader issue of whether it
is right for Policy to say

Perl programs and modules should follow the current Perl policy.

or

Perl programs and modules must follow the current Perl policy.

I think this is actually quite tricky: if packages must follow the Perl
policy, does that erase the difference between 'should' and 'must'
requirements in the Perl policy?

If someone thinks it is a big deal that Policy says only that packages
should follow the Perl policy, and is willing to do the work to handle
these complexities, they should file a new bug against Policy.
Otherwise, let's put that broader issue aside and just fix this
confusing inconsistency about shebangs.

-- 
Sean Whitton


signature.asc
Description: PGP signature