control: tag -1 +patch
Hello,
On Fri 24 Aug 2018 at 08:44PM -0700, Russ Allbery wrote:
> I'm looking for seconds for this patch to relax the current requirement
> back to a should. After that, I think the next step would be to introduce
> automatic fixing of the #! line to debhelper, since
On Fri, Aug 24, 2018 at 08:44:26PM -0700, Russ Allbery wrote:
> Dominic Hargreaves writes:
>
> > Clearly it should not be a must at this point given the deviation:
> > though it still looks to me like a must ever since it was added to the
> > perl policy, so if it is changed it should be changed
Hi Russ,
Russ Allbery wrote:
> I'm looking for seconds for this patch to relax the current requirement
> back to a should.
[...]
> --- a/perl-policy.xml
> +++ b/perl-policy.xml
> @@ -533,7 +533,7 @@ $(MAKE) OPTIMIZE="-O2 -g -Wall"
>Script Magic
>
>
> -All packaged perl
Dominic Hargreaves writes:
> Clearly it should not be a must at this point given the deviation:
> though it still looks to me like a must ever since it was added to the
> perl policy, so if it is changed it should be changed in both places.
Hi all,
I'm looking for seconds for this patch to
Norbert Preining writes ("Re: Bug#906901: debian-policy: Perl script shebang
requirement is disturbing and inconsistent with rest of policy"):
> Hi Ian,
> > This confusing user experience only occurs if someone prepends a
> > different perl to $PATH. Has anyone actual
Hi Ian,
> This confusing user experience only occurs if someone prepends a
> different perl to $PATH. Has anyone actually ever done this and got
> useful results ? Has anyone actually even wanted to do this ?
Not that I know off in a separate PATH, but I have seen perl in
/usr/local/bin quite
Julian Andres Klode writes ("Bug#906901: debian-policy: Perl script shebang
requirement is disturbing and inconsistent with rest of policy"):
> In fact, we're seeing upgrade failures due to people having
> different interpreter versions in /usr/local, and there was some
> di
Jonathan Nieder writes ("Bug#906901: debian-policy: Perl script shebang
requirement is disturbing and inconsistent with rest of policy"):
> Dominic Hargreaves wrote:
> > On Tue, Aug 21, 2018 at 08:42:11PM -0700, Russ Allbery wrote:
...
> In this thread, there are three p
On Wed, Aug 22, 2018 at 07:04:10PM -0700, Jonathan Nieder wrote:
> Hi,
>
> Dominic Hargreaves wrote:
> > On Tue, Aug 21, 2018 at 08:42:11PM -0700, Russ Allbery wrote:
>
> >> I do feel like allowing either based on the whim of the packager is just
> >> kind of bad. It produces inconsistent
Hi,
Dominic Hargreaves wrote:
> On Tue, Aug 21, 2018 at 08:42:11PM -0700, Russ Allbery wrote:
>> I do feel like allowing either based on the whim of the packager is just
>> kind of bad. It produces inconsistent behavior to no real benefit for
>> anyone. If you install a Perl earlier in your
Hi,
> Addressing your inconsistency argument above: I can certainly see an
> argument that some types of perl scripts shipped in Debian might want
> to opt into being run by a different interpreter for special reasons,
> but I think they should be the exception rather than the rule. Having
I am
On Tue, Aug 21, 2018 at 08:42:11PM -0700, Russ Allbery wrote:
> Russ Allbery writes:
>
> > Did Lintian have some special case that was allowing /usr/bin/env perl
> > previously and then Lintian changed based on Policy? That would be
> > unfortunate, since we thought we were changing to match
On Wednesday, 22 August 2018 13:26:30 AEST Ian Jackson wrote:
> In practice, replacing perl with a homebrewed actual perl is rare and
> in that case you want to put it in /usr/bin, because that's where all
> distributed perl scripts expect it to be.
(If you'd make it /usr/bin/perl anyway, isn't
Russ Allbery writes ("Bug#906901: debian-policy: Perl script shebang
requirement is disturbing and inconsistent with rest of policy"):
> Yeah, this is one of the points that I'm struggling with: I feel like our
> stance with Perl (and Python) and our stance with ma
Hi,
On Tue, 21 Aug 2018, Russ Allbery wrote:
> Perl folks, the short version is that Lintian wasn't actually checking for
> scripts that used /usr/bin/env perl, so our check when we closed #683495
> was bogus. Lintian has now changed based on Policy, and it looks like
> there were around 2,000
Hi
> Apparently the Python packaging community in Debian already had this
> discussion and chose to standardize on /usr/bin paths for everything, and
> the debhelper add-ons for Python just rewrite the #! line accordingly. So
Hmm, really? Looking throught the python scripts in TeX Live I find a
Norbert Preining writes:
> But we probably have the very same situation with any other interpreter.
> ANyone ever checked the shebangs of python/php/lua/whatever scripts?
Apparently the Python packaging community in Debian already had this
discussion and chose to standardize on /usr/bin paths
Hi Russ,
> Unpredictable behavior, where every command written in Perl behaves
> randomly based on the whim of the packager?
Well, so it be?
> commands in maintainer scripts). But picking one or the other essentially
> at random (from the perspective of the user) sounds awful.
But we probably
Thank you for the background on Python!
Stuart Prescott writes:
> Sidenote: Getting rid of env in shebangs is only part of the story to
> making packages robust against accidental breakage. Putting an
> incompatible interpreter into PATH (say, /usr/local/bin/{python,perl})
> ends up breaking
Norbert Preining writes:
>> If you install a Perl earlier in your PATH, you get totally
>> unpredictable behavior, and everyone will be unhappy half the time.
> Well, but this is what you have asked for when you installed a Perl
> earlier in your PATH. It is up to you.
Unpredictable behavior,
On Tuesday, 21 August 2018 20:42:11 AEST Russ Allbery wrote:
> I do feel like allowing either based on the whim of the packager is just
> kind of bad. It produces inconsistent behavior to no real benefit for
> anyone. If you install a Perl earlier in your PATH, you get totally
> unpredictable
Hi Russ,
> there were around 2,000 scripts in Debian that were using the /usr/bin/env
> perl form.
That was a number I somehow expected. It is decades old practice to use
this shebang.
> Any feelings about where we should go from here?
Yes.
> I do feel like allowing either based on the whim
Russ Allbery writes:
> Did Lintian have some special case that was allowing /usr/bin/env perl
> previously and then Lintian changed based on Policy? That would be
> unfortunate, since we thought we were changing to match Lintian
Sigh. Yes, indeed.
* checks/scripts.pm:
+ [CL] Policy
Russ Allbery writes:
> Norbert Preining writes:
>> If a user/system admin wants to replace Perl by prepending the path to
>> a self compiled Perl to the PATH, it is his right to do so, and Perl
>> scripts are expected to follow this decision. It is the obligation of
>> the one doing the change
Control: severity -1 normal
Norbert Preining writes:
> The recent addition to the Debian Policy to require a Perl shebang of
> /usr/bin/perl is inconsistent with the rest of script usage, and hinders
> the user/system administrator to freely override Perl.
This isn't recent. All we did was
Package: debian-policy
Version: 4.2.0.1
Severity: serious
The recent addition to the Debian Policy to require a Perl shebang of
/usr/bin/perl is inconsistent with the rest of script usage, and hinders
the user/system administrator to freely override Perl.
If a user/system admin wants to replace
26 matches
Mail list logo