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

[Paul Harvey]

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.

- Paul