[Build-common-hackers] Bug#586859: Bug#586859: cdbs: upward compatibility
user42 at zip.com.au
Sat Jun 26 01:04:26 UTC 2010
Jonas Smedegaard <dr at jones.dk> writes:
> The reason for deprecating perlmodule.mk is that more Perl build
> systems emerged than the initially implemented MakeMaker one,
I think perlmodule.mk may helpfully run makemaker the way it has.
I don't think it matters if the name is no longer quite right.
Rate the name as an historical accident. In the docs say that with the
benefit of hindsight the name might have anticipated future perl build
schemes, but I don't think anything would be gained by everyone editing
their rules scripts just for that.
> I was not able to find a way for perlmodule.mk to (elegantly
> backwards-compatible) support both those upstream build systems.
I suppose the ways to force settings among the different schemes are all
> 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.
The advantage of a break like a /2/ bump would be that users who go to
it know they've bought into various changes. But it doesn't look like
it's at that stage. Adding nice new things into /1/ shouldn't mean the
existing ones have to be taken away. If in time the cruft builds up too
high then a /2/ could cut it down to what turned out to be the best
> 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?
What need to remove at all? The simple patchsys likewise. It tends to
strike me in various contexts that leaving stuff is simultaneously the
least work for everyone, and the most compatible :-).
More information about the Build-common-hackers