On Thu, Jan 28, 2021 at 10:21:21PM +0100, Paul Gevers wrote:
> Hi Dominic,
>
> On 28-01-2021 22:05, Dominic Hargreaves wrote:
> >>> 5.32.1 would need a binnmu of a few leaf packages
> >>> (libpar-packer-perl libdevel-cover-perl libclass-xsaccessor-perl
> >>> libcommon-sense-perl) as usual.
> >>
> >> Just to be clear, these binNMU's would be needed too if we would go for
> >> the cherry-pick option?
> >
> > No, the binaries relate to a change of upstream version number
> > which ends up being encoded in these packages. If we cherry pick
> > fixes, the binNMUs wouldn't be needed.
>
> But then, that relation is strictly speaking too tight? Is that
> something that can be improved (without jumping through hoops)? Maybe
> not for this time, but for future changes. Normally perl packages look
> for the perl-something-api right? Which would make it clear that this is
> no transition.
There's a reason for each of them of course.
libpar-packer-perl (#551356) would definitely involve jumping through
hoops. It's the worst one of the four I think and really requires a
tight dependency.
The version skew warning in libdevel-cover-perl (#562214) could probably
be patched away easily, but that seems a bit risky to me. Presumably
upstream has a reason for the check. I'm not sure if we've ever asked
though, and OTOH autopkgtest runs should notice if the newer Perl version
breaks something.
For libcommon-sense-perl, I quote #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.
libclass-xsaccessor-perl only has this changelog entry:
* Add dependency on same upstream version of perl to make sure
#define PERL_CORE never breaks things.
[...]
-- Ansgar Burchardt <ans...@43-1.org> Wed, 18 Aug 2010 13:21:04 +0900
Not sure if that one could be relaxed but keeping it tight seems prudent
to me.
As Dominic said, the related binNMUs have not been much of an issue in
the past.
--
Niko Tyni nt...@debian.org
