[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Possible framework for `debmake replacement'

>>"Ian" == Ian Jackson <ian@chiark.greenend.org.uk> writes:

>> I too am dubious about the "compiler" form of deb-make
>> replacement. The problem is that it does not catch up as policy
>> changes. It would be very difficult to make a "compiler" form of
>> rules builder that would automaticaly incorporate policy changes
>> into existing packages as deb-make often does. Once you edit the
>> generated script, you don't want to send it back through the tool
>> again and lose your changes.

Ian> I disagree.  The model I have is that the developer would never
Ian> edit the compiled rules file.  After all, developers do not edit
Ian> configure scripts generated by autoconf.

	I wish we would stop restricting ourselves with the
 charecteristics of autoconf.

Ian> I think the compiled model gives us the best of both worlds: old
Ian> packages can still build, and still build what they always did,
Ian> but to update to the latest policy specs you can rerun the
Ian> compiler.

	*And* not loose any changes they made, they can then choose to
 massage their changes, or throw them away and start with the base
 actions (generated by the ``compiler'').

Ian> I think that it should be possible to rebuild a package after
Ian> making a minor change without having to install a particular
Ian> version of the packaging helper tool.  This rebuild should not
Ian> produce a radically different package.


Ian> Otherwise, if we find a serious bug in a now-superseded package
Ian> we'll have great difficulty rebuilding it to fix only that bug,
Ian> and will have to risk pushing the latest version into our stable
Ian> tree.

Ian> Note that the requirement not to edit the generated rules file is
Ian> no worse than the requirement not to edit a run-time script
Ian> called by the rules file: in both cases exceptions and facilities
Ian> for overriding need to be handled by the assistance tool, either
Ian> in a generic or specific way.

	But I fail to see why we should have this rectriction at all
 if we do not need to.  Just because a restriction is not too Draconian
 fails to make it desirable.


 "Slime is the agony of water." Jean-Paul Sartre
Manoj Srivastava               <url:mailto:srivasta@acm.org>
Mobile, Alabama USA            <url:http://www.datasync.com/%7Esrivasta/>

Reply to: