Re: Possible framework for `debmake replacement'
>>>>> "David" == David Engel <email@example.com> writes:
David> You keep saying you want a utility that will spit out the "list
David> of commands" to be executed rather than actually executing them
David> so you can paste them into your own rules files and edit them.
>> Not in the default case. But if I do have to edit something, I
>> should only have to edit a part of the rules (not the take it or
>> leave it attitude of debstd or single megalith files). The process
>> should make it *easy* for me to change things, but not require me
>> to take any action unless I have to. No editing required for
>> simple, default cases.
David> I think we have a philosophical difference here. I agree that
David> the process should make it *easy* for you to modify things, but
David> not by allowing you to pull out it's internals and customizing
David> them to suit your needs. This would severely restrict the
David> ability to change those internals as the need arises without
David> risking breaking every package that uses those internals
I think Manoj's suggestion is good. If there was a --no-exec option
in debstd, the maintainer may use debstd --no-exec as a *policy
checker*. debstd is not explicitly used in the rule file, the
maintainer is still in control of the rule file. The required
modification to debstd is minimal (I think) but this option would help
the skepticals who are not taking advantage of debstd in any way.
I can't see how this option would ``breaking every package that uses
those internals directly''. When there are policy changes, a
maintainer has to modify the rule file himself if he is not already
using debstd. How can some advice from debstd --no-exec do any harm
to the package?
Billy C.-M. Chow <firstname.lastname@example.org>
Department of Systems Engineering
The Chinese University of Hong Kong
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-REQUEST@lists.debian.org . Trouble? e-mail to Bruce@Pixar.com