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

[Dominic Hargreaves]

On Mon, Mar 25, 2013 at 02:00:03PM +1100, Paul Harvey wrote:
> For the Foswiki project, we can deal with things as-is.
> 
> But you have created a new bug, Locale::Maketext 1.23 is being
> shipped as 1.19 and I still don't see how this can ever be a good
> idea. These two versions have different version numbers for a
> reason: there has been a deliberate change which the caller must
> 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
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
owing to the deep freeze that Debian is now in. I would certainly want
to get the release team's opinion on any further changes (such as pulling
in the updated Locale::Maketext verbatim).

> Our hack to detect Debian's special franken-version is exactly that,
> a hack - and additional complexity we'd very much rather not incur
> at runtime. Or complicate by pre-computing from yet another
> admin/configure UI prompt which could get out-of-sync should
> liblocale-maketext be updated (resulting in double-escaping mess
> until the user re-runs configure UI).
> 
> Perhaps I don't know enough about Debian infrastructure but how can
> this situation be easier to deal with than simply updating the rest
> of the .pm including the $VERSION string and POD lines? Especially
> given that your own grepping hasn't exactly overwhelmed with many
> dependencies on Locale::Maketext.

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.

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