On Fri, Jun 21, 2002 at 03:09:17AM -0400, Clint Adams wrote:
> > That, however, isn't the question being discussed. The question is whether
> > I'm going to *support* them in doing so: fix problems that wouldn't have
> > existed if they hadn't done so, or avoid creating them in the first place.
> Well, no one's forcing you to comply with policy.
Yeesh. I don't know what so hard about this. The following statements are
true.
I am not an idiot.
I do not need to be forced to follow good advice.
Policy is by and large good advice.
You don't have to force me to follow policy, as long as you make it
sensible. If you've got a good reason to allow any POSIX compatible shell
as /bin/sh then *tell* me it, and I'll happily support you all the way.
> > The other question which I've been implying for a couple of messages
> > now, is if we do support them, how should we prioritise it in relation
> > to other issues. And the answer to that should be, IMO, nowhere near as
> > highly as DFSG-freeness or security problems.
> Fine. Fix all the DFSG-freeness and security problems in your packages,
> then change those daunting 6 octets.
See the problem is that right from the start you've tried prioritising
them at the exact same level as DFSG-freeness and security
problems. That's what the release critical severities are there for.
> > If it seems so bizarre, perhaps it's an indication that you're not
> > grokking what I'm saying.
> I'm not even close to grokking it.
Then please, pay attention. I've explained this a dozen times on this
list already, so if you need a different wording surely there's someone
out there how can provide it.
Release critical bugs are _very_ rare. They're not for problems that we're
annoyed or embarrased about having, they're not for policy violations
in general, they're not for setting goals that need to be done in lots
of packages.
They are *purely* for those issues which are so severe that they're worth
removing packages because of, or saying "I'm sorry, we can't release on the
day I said, because these issues are unresolved."
I had hoped that letting policy have some influence on which policy issues
should be considered release-critical would help ensure consistency
and a deeper analysis of potential release-critical issues. Instead it
seems to be an excuse for people to raise every other policy issue to
release-critical status, and I have to either repeatedly argue against
it and live with all the mistakes made anyway (like the "must" idiocy
related to /bin/sh).
And yes, after eighteen months to two years of having to explain this
again and again and again and again -- in spite of it being pretty
clearly written in policy itself -- my patience is pretty short on the
whole issue.
> > and I'm far from knowing much about POSIX, but the specification for
> > echo doesn't seem to be doing much to improve compatibility, as far as
> > I can see.
> No, the previous specifications haven't done much for compatibility.
> They said "we don't have a clue what echo will do when you give it crazy
> things like arguments, so use printf instead." Only nobody used printf.
> Why? Because echo is typically a builtin, and printf is a builtin in
> only a few shells.
>
> Now, if echo doesn't behave the way they say, it's buggy.
...and very few shells implement it the way POSIX says, so scripts that
want to be portable can't rely on what POSIX says.
> > Because we're already able to support /bin/sh -> ash,bash, and we're
> > doing okay at keeping that support.
> A quick scan of the BTS suggests that at least 824 bugs are about ash
> not working with #!/bin/sh scripts.
How many of them are marked "serious", exactly?
For that matter, how many of them are in base or standard packages?
> > Which seems to support the "no practical benefit" argument, no? There're
> > plenty of developers running different shells in places where it does
> > matter (particularly their login shell).
> If it didn't matter, why did people fight for ash? There was a fight,
> remember?
I don't really see why you need me to make your arguments for you, but
whatever. The argument for ash's utility is its self-evident smallness
and claims that it's (therefore) faster to use. I haven't actually seen
any benchmarks to back up the latter, but the theory certainly seems
reasonable. Further, some developers actually do run ash as there /bin/sh,
no matter what the majority of developers do.
> > Hello, release-manager.
> > You realise you filed most of those /bin/sh bugs as release-critical
> > bugs, right?
> I filed them as severity serious. I did not make 'serious' bugs RC. I
> did not associate 'serious' with policy violation. That being said, my
> conception was that RC bugs were those of priority serious or higher
> which hadn't been specifically excepted by the release manager for
> arbitrary reasons. Now, seeing as how woody is frozen, and testing is
> not running, I don't see how this has any practical impact anyway.
Yeesh. Testing's going to run again sooner or later, and, if you don't
downgrade them first, I'm probably going to have to.
This is the sort of idiocy that "serious" was introduced to try to stop:
you don't just randomly make things "release critical" because they annoy
you, you do it because they're a huge detriment to the distribution as
a whole. For potato, various neophyte users were doing it, which was
understandable since they had no reason to know better. Now it seems to
be everyone subscribed to -policy instead.
> > Evidently. If you want to get them all fixed before the next release,
> > file them early, and check up on their progress in a couple of months. The
> > severity has *nothing* to do with that.
> This certainly seems early, and if the severity is irrelevant then stop
> harping on it.
The severity is irrelevant to getting them fixed. It's not irrelevant
to the success of the next release, the ease of managing this release,
as a precedent for the next idiot that wants to file a dozen serious
bugs about their pet project, or my annoyance level generally.
> > If you want to argue about what should be the case, I'll take arguments
> > about practical utility and difficulty over policy's opinion any day.
> practical utility: compatibility and portability
So, you're not willing to justify "size" and "speed" then? There aren't
any features that can be offered by other POSIX shells to #!/bin/sh
scripts?
I presume you mean compatability and portability of our scripts to other
systems, or is there more to it than that?
> > For the former, the echo -n exemption isn't nearly enough: we also need
> > a fancier test, command -v, we don't support the funny \c characters in
> > echo, and probably various other things.
> Nope. All unnecessary.
Really? Please try having debootstrap install a shell without the above
(command -v and a test that supports -o and -a) as soon as bash is
unpacked, and see how far you get.
> POSIX sh lacks a lot of useful and convenient
> features. It might be nice to have such things in #!/bin/sh scripts.
> It might be more efficient to have such things in #!/bin/sh scripts.
> But you don't need echo -n if you have echo '\c',
See that's a nice claim, but it doesn't seem to have anything to do with
reality. Most of the echoes we have don't give us \c.
> Now, the question is whether we want to add further exceptions to
> policy, and what the relative merits would be. There has been support
> for SUSv3 + UP + XSI, subsets of that, and a reluctance to change the
> current verbiage, if I am summarizing correctly.
>
> The more I think about it, though, the less I agree with Herbert about
> the UP/XSI stuff and the more I favor strict SUSv3.
See, ash was argued for (as far as I've ever seen) on the basis of it
being faster. I can't see replacing builtins with convoluted little
functions, and type with &&'s and ||'s as helping that.
Who's our primary audience here, Debian users or people who want to pull
apart our packages and use them on Solaris systems?
Does "optimise for the common case" really ring that hollow?
> > Policy isn't a stick to beat people with, even when they make the most
> > appalling idiocies. Stop pretending it is, or that -- if it isn't --
> > that we have no other possible recourse to ensure we produce a high
> > quality system.
> If I insist on making packages with all their files in /usr/local/djb,
> and people file serious bugs against them, and I ignore them, what might
> a release manager say?
That FHS is a release-critical issue, unlike, say bashims. Although
certain parties think I'm being overly anal about that, too.
> > If you can't justify a change without reference to policy, then you
> > shouldn't be suggesting it, let alone demanding it. Policy's a convenient
> > way to make sure you don't have to endlessly repeat yourself when filing
> > bugs, or explaining to new maintainers how things should be packaged, but
> > it's not a substitute for good sense.
> What makes you think you're expositing good sense?
Huh? I've tried explaining why I think all the above is good sense when I
said it. It's a little ridiculous to ask me to go through every argument
I've made in this thread and repeat my justifications why I think it's
good sense as a parting jibe, don't you think?
As an alternative, let's make a really simple summary.
(1) bash and ash are the only /bin/sh's that are realistically
supported by Debian at the moment. If you try to use
anything else, you'll get random breakages everywhere, in
base packages, commonly used ones, wherever. If you use ash,
you'll generally be okay, but there's still a fair bit of
flakiness. If you use bash, you should be fine.
(2) There's no benefit to anyone using a shell other than ash or
bash as /bin/sh on a Debian system.
(3) Having Debian's /bin/sh scripts work on
SUSv3-with-no-extensions makes them more portable, which can
help admins of random other Unix systems. However, not all
SUSv3 scripts will work on Debian (due to the echo -n issue,
at least)
Hrm. Is there anything more to this issue that actually affects anyone
using Debian? I can't think of anything. So that just leaves:
(4) Debian Policy underspecifies or misspecifies /bin/sh: it's not
clear which POSIX extensions can be expected (eg, policy
uses test's -a/-o/() parameters in some examples)
(5) Clint wants to remove the -n exception for echo, which
contradicts (rather than extends) POSIX.
Do you really disagree with any of the above, in a way that you can
actually manage to justify with something beyond handwaving? Can we
possibly use this as a basis for establishing some sort of consensus on
this issue?
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:
pgpwPicijmqbU.pgp
Description: PGP signature