hi Kevin (and others), On Wed, Jun 23, 2010 at 10:31:13AM +1000, Kevin Ryde wrote:
I hoped perlmodule.mk and other fragments wouldn't print messages saying they shouldn't be used. One of the most attractive things about cdbs is that straightforward uses have been forward and backward compatible for a very long time -- unlike other packaging tools which seem to run a treadmill forcing developers to make one change after another to stuff that was working fine. I thought in fact also the reason for the /1/ in the cdbs names was so existing ways could be left alone should there be new things.
Good point - in general.I do believe, however, that a lifespan of 7 years for perlmodule.mk isn't particularly short.
The reason for deprecating perlmodule.mk is that more Perl build systems emerged than the initially implemented MakeMaker one, and I was not able to find a way for perlmodule.mk to (elegantly backwards-compatible) support both those upstream build systems.
I prefer replacing single snippets over bumping epoch (the /1/ in current path) whenever possible, to affect as few users as possible with each change.
I write "I" in the above even if we are multiple people working on CDBS, as it is something we haven't discussed as a team.
I welcome input on this - both from team members and users (and hey - do consider step up and join the team: you need not be an übergeek or even be official Debian Developer to join, just have a passion in CDBS and a occasional bit of spare time).
Would it perhaps help to include in the warning a promise on how long the deprecated snippets will be kept alive? How long should that be?
I suggest keeping this bugreport alive to discuss also what things might be interesting for an epoch bump.
- Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private
signature.asc
Description: Digital signature
