[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Package maintainer script policy.

>>"Raul" == Raul Miller <rdm@test.legislate.com> writes:

 Raul> Manoj Srivastava <srivasta@datasync.com> wrote:
 >> We are talking about a general policy here; and I do not think
 >> we can make ad hoc generalizations about quality control like this. I
 >> am not willing to vote for a draconian policy proscribing binaries in
 >> postinst based on shaky grounds like this. 
 >> Are there better reasons?

 Raul> Did you miss that by examining the object code of that postinst script
 Raul> I found that it violated policy (does not respect $PATH when calling
 Raul> ldconfig)?

	This is a particular example, and moreever, one that is not
 correct, as has been pointed out. One does not make policy based on
 one (flawed) example. 

 Raul> However, I also argue that scripts which use /bin/sh or /usr/bin/perl
 Raul> are easier to maintain (and audit, and get working right) than C code.

	Depends on the person coding it. If you do not know perl/
 shell scripting, but are a C guru, things can be cvery
 different. Nothing that deserves to go into the policy so far.

 Raul> I'd argue that that a dynamically linked executable has *NO* reliability
 Raul> advantage over a script.  Both can be knocked out if the libraries they
 Raul> need are not present.

	OK. But no disadvantage either. Again, nothing to base a policy
 of exclusion on.

 Raul> So what we have here is one package which introduces extra complexity
 Raul> and bulk for no gain.  And, by the way, it's buggy, but this is not
 Raul> immediately obvious from looking at it because of this extra complexity
 Raul> and bulk.

	You are still talking particulars. Yes, a postinst may be
 buggy, script or exec. Nothing can be generalized from that
 statement. (Is this the same bug that turns out not to be a bug? Or
 something else?). Again, nothing to base a policy decision on.

 Raul> How good of a reason do you need?

	Any good, general reason would do. I have found none in this

        If I find a bug in a C program, I don't go asking for a policy
 to exclude all C programs from the system. How is what you are asking
 any different, as far as this message goes?

 "Let's not be too tough on our own ignorance.  It's the thing that
 makes America great.  If America weren't incomparably ignorant, how
 could we have tolerated the last eight years?" Frank Zappa, Feb 1,
Manoj Srivastava  <srivasta@acm.org> <http://www.datasync.com/%7Esrivasta/>
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E

To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Reply to: