[Build-common-hackers] Bug#586859: Bug#586859: cdbs: upward compatibility

Jonas Smedegaard dr at jones.dk
Wed Jun 23 09:40:01 UTC 2010

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/build-common-hackers/attachments/20100623/a1baaaa7/attachment-0001.pgp>

More information about the Build-common-hackers mailing list