[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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



> 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, 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.  Using
zsh, well, I don't know why anyone would want to do that.  Same goes for
ksh93.

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

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

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

As I recall, the ash-blessing was not as pleasant as you imply.

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

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

> 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.  One way you have a clearly defined interface.  The
other way you have aj saying "that really just means bash or ash."

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

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

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

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

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

Perhaps you see value in the following scenario: aj uses bashisms which
don't work in ash in all his #!/bin/sh scripts.  Clint uses ashisms
which don't work in ash in all his #!/bin/sh scripts.  Apparently, now,
neither shell can be used as /bin/sh.  Both file bugs, and are told to
fuck off.  Everybody wins.

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

Occasionally, citizens of certain countries are told that they have
freedom because they can choose between two parties instead of one.

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

I think you mean /bin/zsh.  The symlink fiesta is due to a convoluted
transition process.  The only reason the zsh binary was moved to /bin is
because people complained about not being able to use it as /bin/sh.

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

Interesting.  Bug #150405 was reprioritized to severity CLOSED, not
normal.  Does the -done mail not accurately depict the rule here, or
vice-versa?

> We can't get that? Since when?

Let's see.  I filed about 17 bugs related to these topics.  Two have
been fixed and uploaded.  One has been fixed pending upload.  One has
been closed with a refusal.  One has been left open pending outcome of
"penis war".  One has been left open in the hopes that I will be able to
submit sufficient proof that a policy violation is a bug.  Possibly
sufficient proof is a demonstration that it might break something on
Solaris.  The rest have not yet been acknowledged, but due to the high
quality of Debian, I suspect that I'll get responses on all of them
within 3 years.

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

Is this haiku or hyperbole?

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

I'm glad that you admit that it's still in question.

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

Point taken, though, in fact, I'm not the only one.  cf. bug#150518,
f.ex.

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

No one needs permission to file bugs.  That would be silly.

> Sorry, Manoj is cool and all, but he's not a walking talking consensus
> all by himself.

The impression I got from him was that it was highly unlikely that
policy would be changed to allow additional extensions to POSIX.

I allowed weeks for such a possibility before my "bug rampage".

There are two productive outcomes to this: either policy gets changed,
or policy violations get fixed.  No one is forcing you to rearrange your
busy schedule to spend however many hours to change six octets.  I
suspect that the release manager wouldn't even remove these packages
from woody+1.


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



Reply to: