On Sat, Jun 26, 2010 at 11:04:26AM +1000, Kevin Ryde wrote:
Jonas Smedegaard <d...@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
signature.asc
Description: Digital signature
