#579112 debhelper: dh_perl: substitute a dependency on the current perl upstream version

Package:
debhelper
Source:
debhelper
Submitter:
Niko Tyni
Date:
2011-12-10 13:06:09 UTC
Severity:
wishlist
#579112#5
Date:
2009-12-23 20:50:20 UTC
From:
To:
When running Devel::Cover, I get some unsightly warnings:

 t/pod-coverage.t .. ok
 t/pod.t ...........
 This version of Devel::Cover was built with Perl version 5.010000.
 It is now being run with Perl version 5.010001.
 Attempting to make adjustments, but you may find that some of your modules do
 not have coverage data collected.  You may need to alter the +-inc, +-ignore
 and +-select options.

 t/pod.t ........... ok

So we need to tighten up the Depends to match the version of Perl that
libdevel-cover-perl was compiled against.
#579112#10
Date:
2009-12-23 21:09:43 UTC
From:
To:
I get these warnings too, and have always considered them more of an
annoyance than a bug. I have been thinking about how to deal with this
issue, but I have not come up with an elegant solution that would suit
our purpose. I'd love to hear about this from the rest of the group.
#579112#15
Date:
2009-12-23 21:19:29 UTC
From:
To:
lets just binnmu them as we find them?
#579112#20
Date:
2009-12-23 23:07:33 UTC
From:
To:
Yes to this.

But to spot these more easily in the future, we can add some magic to
debian/rules and debian/control to force the dependency.  They'll still
need a binNMU, but I suspect that some automated/manual mechanisms will
pick this up sooner if it causes an installability problem (hopefully
without having to involve pkg-perl at all).

It's only a trivial annoyance with 5.10.0 and 5.10.1, but with future
jumps it could break stuff, in the worst case.
#579112#25
Date:
2009-12-23 23:16:34 UTC
From:
To:
we already have dh_perl which sets perl:Depends for us. perhaps it
could be extended for cases like this to make the dependency break
with new upstream perl versions. I wonder, is there any way we can
tell (from code) that it needs to have the stricter dependencies?
#579112#30
Date:
2009-12-23 23:34:29 UTC
From:
To:
actually, this already happens. for example, libdevel-cover-perl
depends on perlapi-5.10.0. the problem with this is that the new
version of perl-base provides both perlapi-5.10.0 and perlapi-5.10.1.
so we do have a way to deal with this when it really would matter, the
perl maintainers just didn't use it this time (becuase it doesn't
really matter). perhaps it really should have been used this time,
and we should just binnmu everything that still depends on perlapi-5.10.0?
I'm guessing a discussion with the perl maintainer who left it
providing perlapi-5.10.0 would be insightful for us.
#579112#35
Date:
2009-12-25 13:00:04 UTC
From:
To:
(cc'ing perl@packages.d.o)

As 5.10.0 and 5.10.1 are supposed to be ABI compatible, perl-base
currently provides both perlapi-5.10.0 and perlapi-5.10.1. Cf. perl-base
in Etch, which provides everything from perlapi-5.8.0 through to
perlapi-5.8.8.

I think the perlapi-* scheme was devised before upstream settled on a
policy of binary compatibility across minor updates. We could possibly do
with just perlapi-5.10 nowadays (or maybe it should be named perlabi-5.10 ?).

Anyway, I'm not thrilled about dropping perlapi-5.10.0 and requiring 270
or so binNMUs just because Devel::Cover thinks it might have a problem
with a newer Perl upstream version.

I suppose extending dh_perl a bit could give a scalable way to require
binNMUs for selected packages when the Perl upstream version changes.
Just a new flag to substitute ${perl:Depends} with something like
 perl (>= 5.10.1-8), perl (<< 5.10.2~)
would do AFAICS.
#579112#40
Date:
2009-12-25 13:56:52 UTC
From:
To:
It's not the only package, I remember playing with substvars in one
or two other packages before.
But I'm also a bit hesitant about _this_ drastic solution.

That would indeed be nice, and IIRC this idea already came up in the
discussion about the last issue (probably on IRC).

I guess someone[tm] should try to hack up something :)

Cheers,
gregor
#579112#45
Date:
2010-04-18 13:18:10 UTC
From:
To:
-=| gregor herrmann, Fri, Dec 25, 2009 at 02:56:52PM +0100 |=-

How about providing a new substvar? Something like ${perl:Same}  or
${perl:Built} that would expand to a proper >=, << dependency like the
one above.

A new substvar would avoid adding command-line switches to dh_perl,
which may be hidden in a 'dh' call.
#579112#50
Date:
2010-04-25 12:33:57 UTC
From:
To:
clone 562214 -1
retitle -1 debhelper: dh_perl: substitute a dependency on the current perl upstream version
severity -1 wishlist
submitter -1 !
reassign -1 debhelper 7.4.17
thanks

I like the separate switch approach flag better. The case is rare enough that
having an override_dh_perl target is not much of a burden IMO.

But that's Joey's call, assuming he's OK with having this in debhelper.
I'm cloning a wishlist bug.
#579112#69
Date:
2011-12-09 00:18:32 UTC
From:
To:
tag 579112 + patch
thanks

On Sun, 25 Apr 2010 15:33:57 +0300, Niko Tyni wrote:

I'd still like to see this feature in debhelper, preferrably in <= 9,
so I've looked at the code a bit:

In patch 0001-dh_perl-add-S-_s_ameperl-switch-in-v9.patch I've added
a -S switch, that adds exactly these values to ${perl:Depends}, and
can be used with d/compat=9 and

override_dh_perl:
    dh_perl -S

I've implemented this in
0002-dh_perl-add-perl-Current-and-perl-Next-substvars-in-.patch,
again only in compat mode 9, to be used by adding

    ${perl:Current} and/or ${perl:Next}

in d/control's Depends.
(They could also be combined into one substvar.)

1.5 years later I agree :)
Setting the substvars always seems like a waste of resources.

Yup.

Both patches are tested (and can probably be improved perl-wise, e.g.
by using $Config{PERL_REVISION|PERL_VERSION|PERL_SUBVERSION} etc.).
But they give the desired result.

(Unrelated note: not only is the debhelper code nice to read, today I
also detected doc/PROGRAMMING which is very helpful. Thanks, Joey.)

Cheers,
gregor
#579112#74
Date:
2011-12-09 03:03:55 UTC
From:
To:
gregor herrmann wrote:

There's no reason to make this contingent on a compat level, it cannot
possibly break anything sane to add a switch.

The patch would be better if it included documentation. Concisely
documenting how -S is different than -V and when -S should be used seems
difficult.

What packages currently have such a tight dependency on perl?

This doesn't seem to have a strong reason to need v9 either.

But I don't see a reason to support both these methods, and the -S
method seems simpler.
#579112#79
Date:
2011-12-09 15:15:19 UTC
From:
To:
On Thu, 08 Dec 2011 23:03:55 -0400, Joey Hess wrote:

Hi Joey,

thanks for taking the time to look into this request!

Ok, good point.


So -V adds "perl (>= 5.14.2-6)", and -S adds "perl (>= 5.14.2), perl
(<< 5.14.3~)" at the moment.
- libclass-xsaccessor-perl
- libdevel-cover-perl
- libpar-packer-perl

Agreed.


Attached is an updated patch that removes the v9 restriction and
contains the updated POD quoted above.


Cheers,
gregor
#579112#84
Date:
2011-12-09 15:57:38 UTC
From:
To:
gregor herrmann wrote:

Which seems inconsistent, surely -S should not allow an older perl
version than -V?
#579112#89
Date:
2011-12-10 13:03:19 UTC
From:
To:
Hm.

Not necessarily IMO; the semantics of -S is "satisfy the request of
$somepackage to run with the current perl _upstream_ version (now
5.14.2)", independent of the Debian revision.
For arch:any packages the lower bound will be overridden anyway, and
for arch:all packages it should be fine this way.

But I agree that it looks illogical, or at least aesthetically
unpleasing.

A different approach might be that the new option only adds the upper
bound ("perl (<< $nextversion~)"); for arch:any the minimum version
is added anyway, and arch:all packages could use -V additionally.
(In this case I'd rather name it -N (next) than -S.)

Does this make more sense?

(Anyone else from the pkg-perl group following along?)


Cheers,
gregor