Re: RFD: Essential packages, /, and /usr

[Clint Adams <schizo@debian.org>]

> Ah, I see. So, POSIX recognises that there are two distinct traditional
> behaviours, then specifies something that's specifically incompatible with
> both of them, and the GNU utilities?

No, it's specifically compatible with SysV echo.

> If it's not to enable backwards and cross-Unix compatability, why do we
> care about POSIX at all?

I don't know.  Do we care about POSIX at all?

> bash, /bin/echo and POSIXLY_CORRECT /bin/echo all treat "\c" as a literal,
> for reference.

You can file bugs against bash and shellutils if you think they should
comply.

> I suspect this is just talking at cross-purposes, but we do have a
> certification policy&procedure for changing what's allowable as /bin/sh,
> viz editing policy and filing bugs and changing scripts. I don't see any
> reason why that wouldn't be a perfectly reasonable way of doing things,
> and, assuming we could avoid having the bugs gratuitously closed or
> flamewars about them, I'm optimistic you'd agree.

Isn't that what we're doing?

> Certainly: I'd've assumed the same. It turns out we're wrong: our scripts
> don't work with random POSIX-compliant shells, just with bash and ash.

But they don't all work with ash.

> Which is all very well if it's just one script, but it's not so great
> when it's a whole bunch of scripts in a whole bunch of packages. That's
> why we have a special case for mass-filed bugs: discussion and consensus
> *first*, to make sure that that policy is what we actually *want*.

Calling it a mass-filing is a stretch, especially since I did them all
manually.

> I've never tried it, I haven't seen anyone else try it, and given that
> there are a significant number of issues generally, I'd expect some of
> them to cause pdksh problems. Additionally, I haven't seen anyone give
> any reason why they'd want pdksh instead of bash or ash.

Well, if it'll help, I'll try.  bash is large, and is slightly
POSIX-incompatible.  ash is slightly POSIX-incompatible.  pdksh seems to
be more POSIX-compatible than both right now.  But let's skip that right
now, since POSIX compatibility is in question, and I'm confident that
Herbert will have ash up to snuff shortly.  I would estimate that the
vast majority of severity:serious justification:11.4 bugs being filed
on packages contain "bashism" in the subject and cite brace expansions
being used in #!/bin/sh scripts.  While it's called a "bashism" and is
definitely not POSIX-compliant, all the other Bourne shells currently in
the archive support brace expressions.  That includes pdksh.

In summary, pdksh vs. bash gives you some of the size and speed
advantage and more bashism compatibility than ash vs. bash.  Perhaps
it's a compromise solution for those who want a smaller /bin/sh but
don't want the breakage.

> Debian's about choice: if someone wants to rm -rf /usr/bin/perl*, are
> you going to prevent them from doing so because you're in love with perl
> and you're going to marry it?

That's a great question.

> 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.

> 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.

> Well, whether Linux 2.5 is nice or not seems pretty irrelevant.

Of course it does.

> 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.

> You've already given one example where bash is *more* compatible as
> /bin/sh than alternatives (ie, (some versions of?) the Linux 2.5 kernel),

More compatible with the Linux 2.5 kernel build system.  More compatible
with Debian #!/bin/sh scripts right now.  Less compatible with certain
AT&T shell scripts, which special-case bash's allegedly buggy behavior.
Obviously no users running the latter really need something other than
bash as /bin/sh, so I can see that as being unimportant.

> 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.  This makes it
suddenly useful for POSIX script writers.  I imagine that it might be
useful for people importing scripts from SysV too, but who really cares
about that?

> I haven't been able to observe any speed differences between ash and bash,
> so I don't expect I'd see any anywhere else. If you've got something
> where there's an observable improvement in speed in using <some other
> shell> compared to both ash and bash, I'd be interested.

Perhaps I'll manufacture some benchmark tests someday.

> 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.  If you think this is doing good,
how are under 20 bugs some sort of crisis?

> I have no major gripe with that. (Uh, assuming that was the bug against
> whichever of my packages it was) If you're in the mood to downgrade the

It was.

> others to more sensible severities I'd even be happy.

Hmm.

> Seems like a lot of effort to go to for no practical benefit.

Hmm.

> Well, considering you've already asked me to do something to help support
> this particular fetish, you might want to reconsider the importance of
> me seeing any reason whatsoever to help you out.

I didn't realize that policy compliance was some sort of buddy-boy
system.

> 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?

> 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.

> 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.

> Yes. It's also wrong.

Sure.  I think the "echo -n" exception should go away.  Then we'd have
"POSIX-compatible".  I'd also be happy with "POSIX-compatible +
noninteractive UP", and a variety of other combinations.

> If you want to argue about what is the case, I'll take the way the archive
> looks over policy's opinion any day.

The archive is full of bugs.  Are all these bugs actually features?

> 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
difficulty: s/9/s KILL/

> 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.  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', you don't need
grouping in test when you have subshells and and-or lists, you don't
need kill -9 when you have kill -s KILL, and well, you just don't need
local at all.  Something like command -v or type might be nice for some
purposes, but you can simulate the behavior of /usr/bin/which in ash
with a function like

findproggie() {
IFS=": "; for i in $PATH ; do test -x $i/$1 && echo $i/$1 && return 0 ; done ; return 1
}

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.

> For the latter, you're yet to show *any* practical utility in using other
> shells -- and indeed you've demonstrated some reasons why you would *not*
> want to use other shsels, and you've already shown that we've got a fair
> way to go before we do support them.

I don't know why you are pretending that this is a monumental
undertaking.  The most annoying bug I filed was on debhelper, and Joey
resolved that one already.  The rest are one or two line cut&paste jobs,
give or take some research and testing.  The rest, which I haven't filed,
except for two packages, will be solved with a recompile against a
recent debhelper.

> Huh? Surely running scripts present on the filesystem is a POSIX feature?

Well, perhaps.  Is there a formal definition of feature?

> 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?

> 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?


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