Re: debmake: a compromise?
On Wed, 19 Feb 1997, Christoph wrote:
> On 18 Feb 1997, Manoj Srivastava wrote:
>
> > This is what I suggested a couple of weeks back, but was told
> > that the degree of verbosity/tracing was deemed sufficient by the
> > author. I just disagree with Cristoph on this, but it *is* his
> > package.
>
>
> I could implement a -d (DEBUG) option that is much more verbose if it
> helps. I am not sure what people are not seeing that they would like to
> see.
Everything. Basically, debstd does "stuff" automatically. The
stuf that gets done is what we want to see. I don't see how
adding options to debstd, which gets called in the middle of a
rules file, will help. Not unless the rules file can get
executed in a "--no-exec" manner. I think I'd rather see debstd
go through all of its decision making, etc, and insert the
actions it decides to take directly into the rules file. This
would be done during the initial setup phase of debmake instead
of at build time. If this isn't feasable, then the whole process
needs to be changed to let the maintainer see every command
executed by rules, without executing them.
I would personally like to see debstd help to generate a rules
file that could later be tweaked the same way debmake creates
various templates to be tweaked. Adding verbose options to
debstd would be good as well. I'd particularly like to see it
have the ability to tell you why its doing what its doing.
Something like the output from some "configure" scripts.
For example:
debstd: checking for documentation ...
debstd: found foo.1, README, COPYRIGHT
debstd: compressing documentation with gzip -9 ...
debstd: creating directory structure under debian/tmp ...
debstd: installing man page "foo.1" into debian/tmp/usr/man/man1
debstd: checking for binaries ...
etc.
This is probably not a real good example, but you get the idea.
By the way, debstd is not a _simple_ bourne shell script and isn't
all that easy to read. It is at first, but then there are a
couple of functions that are larger than most bourne shell
scripts, and finally the main program. I think the average sh
script writer would have problems reading the code and figuring
out what's happening when (I did). For example, there are if
clauses that go in and out of 6 and 7 levels deep, into and out
of case blocks, etc., all in the same funtion. Tracing the
execution of debstd by reading the script is unappealing (unlike
many other aspects of debmake, which are very appealing).
The fact that we're discussing all of this after the utility has
been written instead of discussing before writing it is what Ian
is objecting to. I'm reluctant to make such objections as I'm
not really qualified to. In the public domain, the "law of the
land" is usually "put up or shut up". People don't usually go
throuth the process of clearly defining a design spec and
implementation plan until they have at least 5000 lines of code
;-)
Thanks
Richard G. Roberto
richr@bear.com
011-81-3-3437-7967 - Tokyo, Japan
--
*******************************************************************************
Bear Stearns is not responsible for any recommendation, solicitation, offer or
agreement or any information about any transaction, customer account or account
activity contained in this communication.
*******************************************************************************
--
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
Reply to: