[Build-common-hackers] Bug#586859: Bug#586859: Bug#586859: cdbs: upward compatibility
dr at jones.dk
Sat Jun 26 11:17:13 UTC 2010
On Sat, Jun 26, 2010 at 11:04:26AM +1000, Kevin Ryde wrote:
>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.
This time around it is too late to "roll back" - the newly named
perl-makemaker.mk has been around for too long to drop it again.
So what is possible is to keep both new and old named MakeMaker snippets
- which is what is done currently, warning that one of them is
Makes good sense to have this more in mind for future changes, though.
>> 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
Oh, I think my point was not clear: I was unable to find a way to extend
the old perlmodule.mk to cover both Perl build systems in that one
You are right that I could have left the perlmodule.mk alone when
providing that new perl-build.mk. My thinking was that those names
would be confusing, as both could indicate that they were generic (and
the fact that the perl-build system provides a rudimentary backwards
compatibility layer for MakeMaker confuses even more), but you are still
right that I could have favored stability higher than beautification of
>> 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
Seems we agree here. I simply did not think of the (now obvious)
alternative approach of simply keep the old generically-sounding name,
so assumed that you would want to use an epoch.
>> 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 :-).
One reason to drop snippets is maintainability. the tarball.mk and
patch system snippets are IMO ugly and have been superceded by the much
more elegant approach of DPKG source format 3.0 (quilt).
Another issue is evolving the snippets to be less monolithic: I have run
into upstream sources containing multiple subprojects each with an own
build system, and I would want CDBS be able to support including
multiple build system snippets, enabled for different sub-roots. I do
not say that perlmodule.mk in particular was flawed like this, just that
generally the process of streamlining the code (which implies attacks on
backwards compatibility due to the nature of CDBS) makes some
evolutionary progress (as opposed to using an epoch) possible.
NB! I do appreciate your input very much, no matter if it seems that I
am against all arguments. :-)
* 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
Size: 836 bytes
Desc: Digital signature
More information about the Build-common-hackers