Re: Package maintainer script policy.
Manoj Srivastava <email@example.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?
Did you miss that by examining the object code of that postinst script
I found that it violated policy (does not respect $PATH when calling
However, I also argue that scripts which use /bin/sh or /usr/bin/perl
are easier to maintain (and audit, and get working right) than C code.
I'd argue that that a dynamically linked executable has *NO* reliability
advantage over a script. Both can be knocked out if the libraries they
need are not present.
So what we have here is one package which introduces extra complexity
and bulk for no gain. And, by the way, it's buggy, but this is not
immediately obvious from looking at it because of this extra complexity
How good of a reason do you need?
To UNSUBSCRIBE, email to firstname.lastname@example.org
with a subject of "unsubscribe". Trouble? Contact email@example.com