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?
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.
We always try very hard to work with vendor perls, which as you probably
know, isn't the done thing - try telling perlmonks or #perl on freenode
you've got this kind of problem, and you'll be asked what kind of idiot
doesn't compile their own local perl.
Then try telling our userbase they must compile and maintain their own
local perl.
I didn't start this message intending to drag out my soapbox - I just
think it's tragic there has to be such a large impedance mismatch
between distros and perlers.
Thanks for listening
- Paul
On 24/03/13 23:19, Dominic Hargreaves wrote:
Hi Paul,
Sorry for the delay in responding to this...
On Mon, Mar 11, 2013 at 02:37:31PM +1100, Paul Harvey wrote:
Hi there,
On Fri, Jan 18, 2013 at 03:06:38PM +0000, Dominic Hargreaves wrote:
...
Debian stable. As such I'd be very interested in hearing from anyone
who has real world examples of this breaking things.
It's worth pointing out that you've now got Locale::Maketext 1.23,
minus the doc changes and version bump. That's the only real code
change between 1.19 and 1.23 - so calling this 1.19 makes life
harder for projects like Foswiki to sanity-check the users'
environment.
This is a regrettable state of affairs, indeed.
Take a look at the Locale::Maketext 1.19..master diff for yourself:
https://github.com/toddr/Locale-Maketext/compare/84a644...master
Compared to the diff which I think was applied in perl-modules:
http://perl5.git.perl.org/perl.git/blobdiff/569ba91fcdabdc53eb4284f860a25273bd7fe4e1..1735f6f53ca19f99c6e9e39496c486af323ba6a8:/dist/Locale-Maketext/lib/Locale/Maketext.pm
Foswiki uses Locale::Maketext when internationalization is enabled,
so we've had our own CVE response -
http://foswiki.org/Support/SecurityAlert-CVE-2012-6329.
As part of the fix, we perform additional escaping before calling
Locale::Maketext if the version is< 1.23.
The Debian-patched 1.19 of course already has the escaping code, so
we end up with double-escaping issues.
As we're now getting user complaints on Debian systems, we will have
to come up with a technical solution to this problem but I think
it'd also make sense for Debian to simply ship Locale::Maketext 1.23
proper.
There's a bit of an awkward issue here in that Locale::Maketext is
bundled with perl, and although I agree it is potentially confusing
to have these sorts of changes applied without version number changes,
changing the version number on the Debian branch is quite likely to be
the source of even more confusion; I don't think there's any precedent for
doing that with a dual-lived module. Practically speaking, I think we will
need to stick with what you'd probably term a workaround, which I assume
is to do some sort of probe for behaviour before using it for real?
Interested in hearing opinions from others, however!
Dominic.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
