On Thu, Jun 20, 2002 at 10:42:15AM -0400, Clint Adams wrote:
> > 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?
> Using pdksh will give you better POSIX compliance,
Having echo aliased to `printf "%s\n" "$*"' would give you better POSIX
compliance too.
There's a reason why we specifically *don't* do that.
> though it looks as
> though Herbert is working to solve this as we speak. Using posh will
> give you better POSIX compliance and facilitate system breakage.
And facilitating system breakage is a win somehow?
> > 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...
> So you maintain that policy really says that /bin/sh may be either bash
> or ash, and nothing else.
No, I maintain that in practice, no matter what policy says, bash and
ash are the only shells that work reliably on Debian, and thus are the
only ones users should consider using as /bin/sh.
I realise this isn't what policy might indicate, and given that I still
haven't seen any particularly good reasons to use any other shell,
I'm much more inclined to consider this a bug in policy than in all the
various packages.
> > 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.
> I brought up command -v on -devel. What was the outcome of that?
As far as I'm concerned, the outcome's that we should be requiring
the UP extension of shells that want to consider themselves /bin/sh on
Debian systems.
> > (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)
> Most commercial apps that I've seen come with shell scripts, yes. Some
> Linux 2.5 kernels won't compile if /bin/sh is ash. Is the bug in ash?
So now you're offering good reasons why we shouldn't encourage people
to use anything but bash as /bin/sh?
> > 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
> You do realize that there's precedent for filing policy violations as
> serious bugs, right?
Considering I invented the serious severity and proposed the various
changes to policy and the BTS to support it, I think I have some vague
idea what I'm talking about, yes.
> > 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.
> No, being able to use a POSIX shell instead of bash as your /bin/sh is a
> significant win.
How, precisely? What practical benefits does using any shell other than
bash or ash as /bin/sh bring you? I've asked this three or four times
now without an answer, so please don't expect me to just accept the
above as fact.
> One way you have a clearly defined interface.
No doubt this is about to be quoted as self-evident hypocrisy or something,
but that isn't as much of a win as you're imagining either, IMO. "Clearly
defined" interfaces that're spelled out in hundred of pages of text, with
a dozen different options, and that're consistently extended in practice
tend to encourage non-compliance, rather than restrict them.
Compare "matches the SUSv3 spec with XSI and UP extensions" and
"works with bash and ash". Which do you think is easier to ensure
compliance with? Which can maintainers most easily ensure is met before
uploading? Which can be tested automatically?
> > 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.
> So, in other words, maintainers shouldn't fix bashisms in #!/bin/sh
> scripts either.
Huh? Are you really having that much difficulty understanding what I'm
saying, let alone agreeing with it? You might've extrapolated the above to
"bashims in #!/bin/sh scripts shouldn't be filed as serious bugs either",
which I'd've completely agreed with, but I've no idea where you got the
above.
You do realise that maintainers are expected to fix wishlist and minor
and normal bugs, right?
> > 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.
> We have? type isn't part of UP; type is XSI.
Sorry, evidently I was getting type and command -v confused.
> Furthermore, if, in fact,
> we need this exception, it should be added. If, on the other hand, we
> need policy to say "scripts must be compatible with both ash and bash",
> then the UP and XSI stuff is irrelevant.
We've already established that we do need this exception: plenty of our
scripts use it thanks to debhelper, so if you have a /bin/sh that doesn't
do it, plenty of stuff will break. Which means you can't set up such a
shell as /bin/sh, and the only question is whether we want to support
that in future.
I'm not really sure what's so hard to comprehend about saying "Yes, I
know we said we'd support all POSIX shells. It's turned out to be much
harder than we expected, so we should admit we only support bash and ash
now, and consider whether we want to extend that."
Policy should follow our goals, not dictate them.
> > 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.
> This entire paragraph makes even less sense to me.
Good grief.
> > Well, you're welcome to enlighten me at any time.
> Do you see a problem with a policy of "packages only need to work for
> the maintainer"?
Do you see how there's a practical benefit to a package working for more
than one person?
Do you see how there's a practical benefit to using a shell other than
ash or bash as /bin/sh?
I'd hope you can tell that my answers to the above would be "yes", and
"no", respectively, and how the answer to the first implies my answer to
your question has to be "yes".
> > 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".
> Why haven't you filed such a bug against policy? I think you should
> not, actually, since changing both to "should" would make the whole
> concept utterly pointless.
No, and I probably won't bother. The whole policy of giving this list
influence over release critical bugs was a mistake, because of, well,
people like you.
Non-release-critical bugs matter. Release-critical bugs get a lot more
press time and attention and get to dress up in fancy frocks and go to
awards nights, but they're not fundamentally more special, and they're
not the means by which we make Debian excellent. Release-critical bugs are
the way we make sure Debian doesn't completely and utterly suck. It's the
way we make sure you can install a Debian system, put it on the Internet,
and still have control over it five minutes later. They're not the way
we ensure that packages we install have useful documentation, or that
they're sensibly configured out of the box, or that window manager menus
are usefully setup to display all the interesting apps you have installed,
or all the other nice things Debian does.
I'm all too well aware that everyone thinks their pet fetish needs to
be made a "must" in policy or it'll be "utterly pointless" to try to do
anything about it at all, but, well, you're wrong.
> Occasionally, citizens of certain countries are told that they have
> freedom because they can choose between two parties instead of one.
And you're being an idiot about it to boot.
Cheers,
aj, suspecting he just gets to go and close a bunch of bugs now and get
flamed for it more, yay, woo, whatever
--
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:
pgp2_vM0GB4EF.pgp
Description: PGP signature