On Wed, Jun 19, 2002 at 02:05:01PM -0400, Clint Adams wrote:
> > Scenario A: Script works on bash and ash, which are the two main shells anyone
> > has a reason to use as /bin/sh on Debian.
> >
> > Scenario B: Script works on bash and ash, which are the two main shells anyone
> > has a reason to use as /bin/sh on Debian.
> Why on earth should this be so?
I don't really care whether it should or shouldn't be so, but it certainly
seems like it *is* so. Using bash minimises the disk space used by shells
and is the most reliable, and using ash is faster. Are there any other
benefits to be had by using different shells?
> Is saying "The standard shell
> interpreter `/bin/sh' can be a symbolic link to any POSIX compatible shell,
> if `echo -n' does not generate a newline." yet another of Policy's
> arrogant lies?
I'm not really sure why you're being quite so emotive as to
call it an "arrogant lie". I'd've called it a "bug" or an
"underspecification". Potato, potatoe, I guess...
And in any event that's my point: if you find a case where packages don't
match what policy says, you need to bring it up on -devel to make sure
it really is policy -- well, your reading of policy -- that's right.
> When I joined Debian, bash was the only choice for /bin/sh. Back then,
> one would have said, "Script works on bash, which is the only shell
> anyone as a reason to use as /bin/sh on Debian, and we don't support
> anything else."
And it worked pretty well, don't you think? Allowing people to use ash as
well wasn't too huge a step, so we made that. We overreached and thought
what we were doing would let people use random other shells as well,
but obviously we were wrong. Whether we want to go further is something
that we may wish to do, or we may not.
> Now, those poor people who read Policy or debconf messages might come to
> the silly conclusion that they could make pdksh or zsh their /bin/sh.
> Or perhaps they will obtain a copy of ksh93 and make that their /bin/sh.
> Perhaps that are even forced to do that to support some horribly-behaved
> commercial software.
Uh, are there any examples at all of the latter? If not, please don't
waste everyone's time by making up problems that don't exist.
(Considering that Linux systems tend not to run non-Linux binaries,
that commercial apps tend to not come as shell scripts, and that most
Linux distributions come with bash as /bin/sh, I can't say it's a very
credible problem)
> Some developers want our users to have this choice. Others don't have
> this as a priority.
Imagine that. You realise there's not a problem with this, right? People
aren't meant to have to cede their priorities when they join Debian (well,
beyond "Our users and free software" perhaps). Filing release-critical
bugs is exactly that, though: forcing everyone to accept your priorities
as the most crucial things affecting their package. Sometimes that's
completely reasonable: for Debian's purposes, DFSG problems and security
bugs have to be considered to be the most important things to fix no
matter what the maintainers personal priorities might be; at other times
it can be questionable: take the FHS violation in #97671 / #143825,
which policy would say should be treated more importantly than (eg) all
the random segfaults in the X server -- which the X maintainer disagrees
with. At other times it's just ridiculous: being able to use zsh instead
of bash as your /bin/sh might be a neat trick if you're a zsh fanatic,
but it isn't any sort of significant practical win to anyone.
> > It happens to be a lot of work to make something comply with the letter of
> > POSIX's minimal specification for /bin/sh, especially since it seems to
> Then you'll appreciate that I did the work for you and gave you a
> POSIX-compliant alternative in the bug report.
No, I won't: what you've done for me is given my a little patch which
affects essentially no one, and given me a dozen new bugs in the RC bug
list that I'm going to have to go through and downgrade or close. Sorry,
but the plusses don't cancel out the minuses.
> > be intent on becoming more minimal as time passes, and since it doesn't
> > seem to worry itself too much with existing BSD or Linux systems.
> I don't get that impression. POSIX actually seems to be improving with
> time.
With the new POSIX / SUSv3, we've found we need to add another exception
along with "echo -n" -- that we need the (non-interactive part of the)
UP featureset in order to ensure the "type" command is available.
> > It's also a lot of work to do heaps of other useful things in Debian: make
> > it release faster, improve it's security, have all the neat new GUI apps
> > get a similar degree of reliability as our server programs tend to have,
> I'm sorry; is woody not released because I'm not spending my time
> working on GUI apps?
Huh? Why would you think that? "Debian will be better if it releases
faster. Debian will be better if it's security improves. Debian will be
better if all the neat new GUI apps blahblahblah." Does it make more sense
if I spell it out as separate sentences? And really, none of the above
have much to do with getting woody out at this point in time, either.
> > and a bunch of other things. I can see obvious benefits from the latter,
> > I can't see *any* benefits from being as obsessive as you're being with
> > the former.
> Mind-boggling, that.
Well, you're welcome to enlighten me at any time.
> > Well, no, that's not really true. I don't mind having random scripts
> > work on random other Unices, that's neat. And I wouldn't overly mind if
> > you'd taken the time to do a little polite write up of why "kill -9"
> > isn't something we should do, post it to -devel along with citations
> > people can easily check to the appropriate standards, and then file
> > minor or wishlist bugs about it.
> Why do you think the bug severity levels are lies too? It violates a
> must directive.
It also violates a should directive in the previous sentence, and
considering the second sentence is just a restatement of the first, that
means policy's buggy. The correct resolution, the one that leads to the
better distribution, is the one that resolves both those directives to
being "should".
> > Because, to be blunt, there are a million things that're a million
> > times more important than whether you can use something other than bash
> > as /bin/sh.
> No, it's the absolute most important thing in the two universes. Have you
> ever had need to put Debian on a small amount of flash, and wanted to be
> as space-efficient as possible? If you have only packages that use
> #!/bin/sh scripts, you can get rid of the Essential bash, and save over
> 400K.
Sure, and you can do that with ash already, which is 82kB compared to
394kB for zsh. You can't do it incredibly reliably because scripts are
allowed to randomly use bash wherever they want to.
Hrm, how strange:
lrwxrwxrwx 1 root root 21 May 5 2001 /bin/zsh -> /etc/alternatives/zsh*
lrwxrwxrwx 1 root root 12 Apr 4 15:26 /etc/alternatives/zsh -> /usr/bin/zsh*
lrwxrwxrwx 1 root root 9 Apr 4 15:20 /usr/bin/zsh -> /bin/zsh4*
The postinst seems right though, so I guess this is some bizarre upgrade
bug. For some reason I've got /usr/bin/zsh listed as an alternative for
/bin/sh in /etc/alternatives/zsh on that machine.
> > Which is what policy is, if you ask me.
> This is also probably why you think violations of 'must' directives
> should get priority 'wishlist' bugs.
No, I think that because policy is buggy. These bugs deserve
wishlist/minor severity only -- that's their correct priority as far as
Debian's users go. Things that don't work in ash deserve normal severity
-- they're not *that* important, but at least people have some reason
to care about that. Given that policy doesn't accurately depict that,
well, there's a bug in policy.
> > No, the professionalism and commitment to excellence of Debian maintainers
> > is what ensures that.
> Well, since we can't get that, perhaps we should set some sort of
> policy.
We can't get that? Since when?
Are you refusing to be professional or offer a commitment to excellence?
Maybe you should quit for the good of the project then. I haven't seen
any evidence of either from you, but I'm happy to take you at your word.
> > Perhaps you should look again at all the packages you've been filing bugs
> > against. If you make /bin/sh something else, and lots of stuff breaks,
> > that's evidence that you're missing a needed feature.
> A feature is needed just because someone uses it?
Well, yes. If things stop working without a particular feature, they
need it.
The question is whether we want to change things so that feature isn't
needed, and if so, how much we want to change that.
> > That's nice. In future, before filing bugs against a bunch of packages
> > for something you think's a policy violation, gain a consensus on -devel
> > about it first. It's a simple rule, and it prevents a lot of annoyance.
> I think that you're the only one who has bothered to claim that it's not
> a policy violation to violate policy.
*shrug* You're the only one who's gone on a bug filing rampage about
it too. Since you're so scarily alone in that, clearly you're wrong.
In any event, that guideline is there for exactly this reason: establish
the consensus that you're right -- even if you don't see how anyone
could possibly think otherwise -- *THEN* file the bugs.
> > You'd think the people who insist on rules being followed to the letter
> > would bother to read and follow them themselves, no?
> Manoj told me to file bugs; I didn't get the impression that he thought
> "must" was a typo.
Sorry, Manoj is cool and all, but he's not a walking talking consensus
all by himself.
Cheers,
aj
--
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.
``BAM! Science triumphs again!''
-- http://www.angryflower.com/vegeta.gif
Attachment:
pgpCtHxlEMPiT.pgp
Description: PGP signature