Re: Possible framework for `debmake replacement'
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.
I disagree. The model I have is that the developer would never edit
the compiled rules file. After all, developers do not edit configure
scripts generated by autoconf.
I think the compiled model gives us the best of both worlds: old
packages can still build, and still build what they always did, but to
update to the latest policy specs you can rerun the compiler.
I think that it should be possible to rebuild a package after making a
minor change without having to install a particular version of the
packaging helper tool. This rebuild should not produce a radically
different package.
Otherwise, if we find a serious bug in a now-superseded package we'll
have great difficulty rebuilding it to fix only that bug, and will
have to risk pushing the latest version into our stable tree.
Note that the requirement not to edit the generated rules file is no
worse than the requirement not to edit a run-time script called by the
rules file: in both cases exceptions and facilities for overriding
need to be handled by the assistance tool, either in a generic or
specific way.
Ian.
Reply to: