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

[Jonas Smedegaard]

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.

Good points!

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 
discouraged.

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 
>all different.

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 
snippet.

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 
filenames.


>> 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
>ideas.  :-)

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

-- 
  * 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/20100626/56fbc38f/attachment.pgp>