Re: Possible framework for `debmake replacement'
Hi,
>>"Ian" == Ian Jackson <ian@chiark.greenend.org.uk> writes:
Bruce>
>> 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.
Right.
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.
manoj
--
"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: