Re: debmake: a compromise?
On Thu, 20 Feb 1997, Christoph wrote:
> On Thu, 20 Feb 1997, Richard G. Roberto wrote:
>
> > 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.
>
> That is a feature wanted. I would be glad if someone wrote a compiler like
> that but I certainly have not enough time to take care of it. I barely had
> time developing debmake using shell scripts...
I think you misunderstood what I meant. You wrote debstd, so I'm
assuming you know what it does. Instead of having debstd execute
the commands it now does, all I want is for it to insert those
commands into the rules file instead. Why does this require
writing a compiler?
>
> >
> > 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 ...
>
> debmake already does list the manpages. README COPYRIGHT are explicitly to
> be specified by the maintainer anyways. Directories are created according
> to the maintainer specified contents of the "dirs" file.
>
> > This is probably not a real good example, but you get the idea.
>
> I am sorry I still do not get the point.
No, I don't think you do. The point is that debstd is too much
of a black box. If it had a way of clueing its user into what
its doing and why its decided to do it, we'd be more comfortable
with it. Having the ability to turn such a feature on and off
with a command line switch would be a good thing. Having
multiple levels of verbosity would be even better.
>
>
> > 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 clauses are all clearly indented and very easy to follow. I have had a
> number of people reviewing debstd and offering improvements /patches.
For the amount of work required for _me_ to review and augment
this code, I'd be better off starting from scratch. That's just
me. I'm sure there are plenty of people with the knowledge and
tenacity to work with the existing code, but I wouldn't consider
them average.
>
> > 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
> > ;-)
>
> Debmake has been written with constant interaction with other project
> members and interaction on debian-devel. debmake is cleanly designed and
> the design has been completely reworked a couple of times in order not to
> have spaghetti code.
It would have been easier to have this interaction before writing
the code. It would have been easier to redesign it, after finding
short comings, with a previous design spec to use as a guide
(independent from any implementation of the design).
Again, I think you're missing the point. The fact that debmake
was written, feedback gotten, debmake rewritten, feedback gotten,
debmake rewritten, etc, etc, etc is Ian's primary objection. You
are apparently taking this way too personally as well. In case
you haven't noticed, this is a discussion on debian-devel about
debmake and you are being extremely defensive and not very open
minded. Just about everybody who uses debmake likes it quite a
bit, but many seem to have the same general reservations about
debstd. Doesn't that tell you anything? Would it be so terrible
to just keep an open mind? Nobody here is asking you to rush to
the keyboard and start recoding.
debmake has a lot of good ideas and you've done a lot of work on
it. I appreciate that, and I apologize if I gave you another
impression. But that doesn't make it something its not. When as
many people find something wrong with _anything_ as have found
shortcomings in debstd, its usually a reasonable idea to listen.
It doesn't even mean that you need to agree, but at least listen.
Lastly, cool out. We're all on the same team at the end of the
day. There's no need to wrap all of this up into any old baggage
you may have with someone else.
I'm out of this thread, so follow up privately if you feel the
need.
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: