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