Bug#695224: perl-modules: Locale::Maketext code injection

[Dominic Hargreaves]

On Sat, Mar 30, 2013 at 10:49:04PM +1100, Paul Harvey wrote:
> Thanks Dominic for your pragmatic feedback,
> 
> On 30/03/13 01:23, Dominic Hargreaves wrote:
> >On Mon, Mar 25, 2013 at 02:00:03PM +1100, Paul Harvey wrote:
> >>consider carefully before use. If the caller can't trust the API
> >>version being reported, what is the point of version numbers in the
> >>first place?
> >I personally think you're slightly overstating this part; in the vast
> >majority of cases where bugfixes are cherry-picked into the Debian perl
> >package and the package version number doesn't get changed, no problems
> >arise. The situation for Locale::Maketext is indeed regrettable and I'm
> 
> The practice you're describing has its place, I'm not saying
> debian-perl is wasting its time - generally speaking.
> 
> But in this instance a breaking change in Locale::Maketext has been
> back-ported. I assume most other fixes which have been backported in
> the past did not fundamentally affect the behaviour of those modules
> (and thus require callers to adapt their code to the new version).
> 
> >arise. The situation for Locale::Maketext is indeed regrettable and I'm
> >sorry we didn't foresee the action-at-a-distance the change has caused,
> >but I don't think we have any practical options at this point, not least
> 
> I guess I'm struggling to get my head around that statement: the
> only, *single* line of code (i.e. apart from
> whitespace/comments/pod) in Maketext.pm which differs with upstream
> 1.23 is now the $VERSION line.
> 
> >to get the release team's opinion on any further changes (such as pulling
> >in the updated Locale::Maketext verbatim).
> 
> I wouldn't be making this noise if I didn't think we already have it
> essentially verbatim already - sans comment/pod lines and the
> $VERSION.
> 
> >In general bug-fixes in Debian are pulled in as minimal fixes
> >without changing the version number. The dual-lived modules in
> >perl make this all the more complex, especially when the modules
> >don't get the security fixes in core (maint-5.14 still has
> >Locale::Maketext 1.19). If we did decide to update the version
> >number of the module in Debian's perl package, notwithstanding the
> >technical breakage likely to result when it comes to the packaging
> >infrastructure and Module::Corelist, I wouldn't be surprised if it
> >resulted in people wondering why we were deviating from the
> >upstream versioning. (This impedance mismatch is in related to the
> >fact that perl upstream are more keen to point people at the
> >CPANed version of modules for bugfixes, whilst in Debian packaging
> >the CPAN version of a module incurs more overhead, so is less
> >preferred. I don't claim to know the right way to deal with this
> >problem, now or in future, but hopefully I've managed to
> >communicate that I don't see an 'obvious' solution. Again, I
> >welcome comments from other readers. Dominic.
> 
> Ok. I can only trust your judgment on this. From my (naive)
> perspective, it seems we're creating avoidable bugs for the sake
> of... I'm not sure. Probably, I really should try to join
> debian-perl somehow so that I can get my head around the
> infrastructure and processes which have lead to this.

Hi Paul,

You can see the full bug log[1] for some continued discussion about this,
but in summary: perl 5.14.2-21, uploaded to Debian today, includes the
real Locale::Maketext 1.23, and this should hit wheezy.

I'd like to draw your attention to [2] where Niko notes that both Fedora
and RHEL contain the fix without the version bump, so you probably need
to keep the heuristic for a while (or persue them for a similar fix to
Debian).

Cheers,
Dominic.

[1] <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=695224>
[2] <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=695224#85>

-- 
Dominic Hargreaves | http://www.larted.org.uk/~dom/
PGP key 5178E2A5 from the.earth.li (keyserver,web,email)