Re: debmake: a compromise?
On Fri, 21 Feb 1997, Richard G. Roberto wrote:
> > 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?
Debstd makes dynamic decisions based on file size etc etc and trough
upgrading debstd you can update the packaging method etc etc. All those
essential features are lost with your approach. Let someone else deal with
those things. "Compiler" was my term to refer to a script that would
generate those commands in the debian/rules file.
> 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.
You can turn most features off.
> 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.
Why would you review the code? Perhaps you also start reviewing the code
of the c compiler and the c library? Maybe they are faulty too and you
cannot trust those?
If you have improvements then share them with me and all will benefit from
it.
> 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).
I am not aware of shortcomings. I have been made aware of problems before
and they were fixed.
> 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.
I have been through those issues again and again and throwing them at me
for the one hundreth time probably does not lead to a very nice reponse
from me. Those who have general "reservations" mostly are not using
debmake or act like you from a general attitude of suspicion that I really
do not understand.
> 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.
I am still not sure what is wrong with it. Sorry. Trying to force me to
add features that are not compatible with the design of the package wont
work.
--- +++ --- +++ --- +++ --- +++ --- +++ --- +++ --- +++ ---
Please always CC me when replying to posts on mailing lists.
--
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: