Re: dual life modules
On Wed, Jan 23, 2013 at 09:11:59AM +0100, Salvatore Bonaccorso wrote:
> On Wed, Jan 23, 2013 at 08:51:08AM +0200, Niko Tyni wrote:
> > On Tue, Jan 22, 2013 at 11:59:17PM +0000, Dominic Hargreaves wrote:
> >
> > > Having this fix only
> > > in one of the two places Digest::SHA appears in wheezy is probably
> > > a Bad Thing, so maybe we should upload a fix for wheezy/perl after all.
> >
> > Yes, I think we should (FWIW). Along with that, I suppose we need to update
> > Breaks: libdigest-sha-perl (<< 5.61)
> > in the perl package to read
> > Breaks: libdigest-sha-perl (<< 5.71-2)
> > so that any buggy versions of the libdigest-sha-perl package
> > can't override the fixed version in the perl package.
> I wonder: Is there anything we (pkg-perl team) should keep in mind
> when trying to fix these issues affecting dual-lifed modules? In
> particular here, as libdigest-sha-perl got an ublock because it
> satisfied it right straightforward.
Not sure. It's not the end of the world if a separate package version
has a bugfix that the core version doesn't - that's usually the norm
for all the bugs fixed upstream between those versions.
So the case probably only concerns fixes for 'major' bugs that are worth
backporting into testing in freeze time. For those, I suppose it would
help a bit if the person fixing it in the separate pkg-perl version
could send us a note (the BTS should be fine; if there isn't a clone of
the bug on the 'perl' side, one should be created.)
The Breaks: part above is somewhat academic for Debian as the change
doesn't really affect stable users, but it might affect derivatives
and should make some automatic checks possible (like ensuring that nobody
releases with an older libdigest-sha-perl but a newer perl by accident.)
Again, it's not the end of the world if they are missing.
In general, our handling of dual life modules isn't really optimal IMO.
We shouldn't really be shipping the core versions of dual life modules
at all if there's a separate package available, but rather make the core
'perl' packages depend on the separate ones. (Possibly excluding any in
perl-base due to its 'Essential' status.)
The main problem with this is that it breaks the expectation of perl 5.X.Y
giving you the particular versions of dual life modules released upstream
with 5.X.Y (as documented by Module::Corelist, for instance.) So far,
I've taken the conservative approach of not deviating from upstream by
breaking that expectation.
Of course, even outside the Debian context the expectation will be
broken the moment somebody upgrades the dual life module from CPAN,
and I think that's generally considered a 'supported' configuration
(whatever that means.) So maybe I'm just too shy.
> It's surely not my intention to make your work harder in any case.
No worries, please keep on fixing bugs :)
--
Niko Tyni ntyni@debian.org
Reply to: