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) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org