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

[Clint Adams <schizo@debian.org>]

> Having echo aliased to `printf "%s\n" "$*"' would give you better POSIX
> compliance too.

No, in fact, it would not.

Compare the output of

ash -c 'echo "test\c"'

versus

printf "%s\n" "test\c"

> There's a reason why we specifically *don't* do that.

You mean, other than the fact it won't work and that Debian policy
states that echo should behave otherwise?

> And facilitating system breakage is a win somehow?

No, I'm pointing out that someone can use a POSIX-compliant shell as
/bin/sh and have a system where fakeroot, debconf, and lots of package
scripts don't work.

Now this would be perfectly fine if the explicit requirement were "ash
or bash" or there were a certification policy&procedure for /bin/sh.
Since neither are true, I would assume something along the lines of the
following:

Bourne shells that make an attempt toward POSIX-compliance when called
as /bin/sh may be installed as /bin/sh.

If the shell fails to accurately interpret a POSIX-compliant script, a
bug should be filed against that shell's package.

If the shell fails to accurately interpret a non-compliant #!/bin/sh
script, a bug should be filed against that script's package.

In other circumstances, I might even wager that a reasonable person
would agree with this.

> 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 don't see what you've got against pdksh.  I imagine that it would work
quite well.

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

Debian is about choice.  If someone wants to write a POSIX sh in Java,
are going to prevent them from using it as /bin/sh because you find it
offensive?

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

Apparently there's not consensus on this, and even if there were, this
wouldn't solve your ash/bash problem.

> So now you're offering good reasons why we shouldn't encourage people
> to use anything but bash as /bin/sh?

No, that was a good reason not to use Linux 2.5.

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

As such, it's bizarre that you seem to object to it.

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

Why do they have to be practical?  Assuming we agree on what benefits
are practical--size, speed, compatibility--then the potential benefits
would be size, speed, or compatibility.

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

I can't imagine where you're getting this from.  Allegedly Apple
ditched zsh as the MacOS X /bin/sh because it would run non-compliant
scripts that bash would choke on.

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

I imagine that "works with bash" if easiest of all.  Why aren't you
pushing for a mandatory /bin/sh -> bash?

> 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 wouldn't say that a brace expansion bug is no more valid than a kill
bug?

> You do realise that maintainers are expected to fix wishlist and minor
> and normal bugs, right?

Are they?  I'll reopen 150405 at severity normal and expect you to fix
it then.

> Sorry, evidently I was getting type and command -v confused.

Unless policy is changed, indications are that the only packages using
"command -v" by the time of woody+1's release will be XFree86.

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

Well, recent versions of debhelper no longer use command -v, nor test
statements with -a, -o, or parentheses, so after some recompiles,
considerably less will break.

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

I don't know how hard you expected it to be, but it certainly doesn't
seem all that difficult to me.

> Policy should follow our goals, not dictate them.

Sure.  Our goals appear to be a choice of POSIX-compliant shells
as /bin/sh.

> Do you see how there's a practical benefit to a package working for more
> than one person?

Yes.

> Do you see how there's a practical benefit to using a shell other than
> ash or bash as /bin/sh?

Yes.

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

Yes.  However, I think the fact that _you_ see no practical benefits as
being largely unimportant.  I am confident that the vast majority of
developers have left bash as /bin/sh.

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

I don't know why you keep going on and on about release-critical bugs.

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

Do you think I waited until after the alleged date of woody's release to
file serious bugs because I was confused?  I have no doubt whatsoever
that all of these could have been fixed before woody froze.  I'm
starting to suspect that this would have been more pleasant, and that
you would have merely downgraded the severities.

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

I'll try to be presumptuous about the meaning of policy now:

| The standard shell interpreter `/bin/sh' can be a symbolic link to any
| POSIX compatible shell, if `echo -n' does not generate a newline.[1]

This means that /bin/sh should be almost POSIX-compatible.  The echo -n
is because POSIX was reluctant, at the time, to take a stance on that
issue.  The reason that /bin/sh can be any POSIX shell is because all
#!/bin/sh scripts are going to be POSIX-compliant with echo exemption,
and therefore will work with any such shell.

| Thus, shell scripts specifying `/bin/sh' as interpreter should only
| use POSIX features.

This isn't a must because such shell scripts must be allowed to use
non-POSIX features, such as start-stop-daemon and what-have-you.

| If a script requires non-POSIX features from | the shell interpreter,
| the appropriate shell must be specified in the first line of the script
| (e.g., `#!/bin/bash') and the package must depend on the package
| providing the shell (unless the shell package is marked `Essential',
| as in the case of `bash').

If this were not a must, then anyone could make a #!/bin/sh script that
would not run on bash, and it would not be a valid bug.  Perhaps you'd
think it was a bug.  Nevertheless, I can imagine one or two maintainers
telling you that bash isn't a supported #!/bin/sh for this package.

I definitely agree that "bash or ash" is a better policy than the
"should" you're claiming has been typoed here.

> And you're being an idiot about it to boot.

I'm not responsible for your lack of cognitive ability.


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