Re: Bug#750017: perl-policy: All packages using Perl vendorarch directory need a perlapi-* dependency
(sorry for the delay and thanks for looking at this!)
On Mon, Jun 02, 2014 at 05:25:02PM +0200, gregor herrmann wrote:
> On Sun, 01 Jun 2014 19:58:31 +0300, Niko Tyni wrote:
>
> > On Sun, Jun 01, 2014 at 05:53:28PM +0200, gregor herrmann wrote:
> > > I've tried this for libcommon-sense-perl now, with the idea taken from dh_perl(1):
> > Looks OK to me. The PERL_CURRENT + PERL_NEXT stuff probably isn't
> > needed anymore.
> I have to admit that I'm still a bit confused by this question.
Thanks for persevering. I didn't think this through. A dependency on
perlapi-* is not the same as 'depend on this Perl upstream version'.
Where the latter is needed (as in for instance for libdevel-cover-perl,
which spits out warnings with minor version skew, (#562214), the
PERL_CURRENT + PERL_NEXT stuff is still necessary.
In the case of libcommon-sense-perl, it's probably overkill but
doesn't hurt much. Quoting myself in #722332:
Not sure if all the internals that common::sense fiddles with are under
the 'no ABI changes in minor Perl version updates' promise. I suspect they
are, but we might still be best off rebuilding it even for minor updates.
which translates to 'perlapi-* might not be enough'.
> My thoughts/concerns/questions are:
>
> - My understanding is that perlapi-$VERSION is going to be increased
> for each release; is this correct? (I _think_ that thasn't always
> happened in the past, or at least several versions have been
> provided by one version of perl-base [0].)
Correct.
> If a 5.20.1 upload will only provide perlapi-5.20.1 then we indeed
> don't need the additional version constraints; but this also means
> a transition with several hundred binNMUs for each minor perl
> release, if I'm not mistaken. (Not the issue here but I was
> wondering ...)
Right. If 5.20.0 gets in sid, future 5.20.1 packages are expected to
provide both perlapi-5.20.0 and perlapi-5.20.1 unless something very
disruptive happens. (If 5.20.1 is the first to make it into sid, we'll
probably just skip perlapi-5.20.0.)
> - But still, even if perlapi-$VERSION will be increased and will be
> unique in the future, this doesn't help for the current perl
> versions in unstable/testing/stable/oldstable. Or should we say
> that we don't expect newer versions of 5.{10,14,18} anyway and a
> backport rebuilt in an up2date unstable/testing/stable/oldstable
> chroot will get the higher perlapi-* dependency and that should be
> enough?
(Given the above, I don't think this question is applicable.)
> On Sun, 01 Jun 2014 19:58:31 +0300, Niko Tyni wrote:
>
> > FWIW I think eventually dh_perl should be changed, possibly with
> > something like the attached patch (which I haven't found the
> > time to test properly yet.)
>
> Yay! That would be much better than messing around in debian/rules
> manually.
> (Not tested but it looks good.)
Thanks for the eyeballs. Now filed as #751684. Testing would be welcome.
If anybody finds the tuits for that, please follow up in the bug.
--
Niko Tyni ntyni@debian.org
Reply to: