[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