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

[Clint Adams <schizo@debian.org>]

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

The preceding three statements are subjective.  I think it's good advice
for the X packages to use "test -x /bin/readlink" instead of
"command -v readlink > /dev/null 2>&1".  Manoj and Branden vehemently
disagree.  Your solution to this, apparently, is using "consensus on
-devel" as a stick to beat people with.

The policy document is objective.  Is it 100% correct and clear?
Perhaps not.  That doesn't make it some sort of best practices document.

> [more ranting about RC bugs elided]

If you really think that it was a mistake, why don't you have it
amended?

> How many of them are marked "serious", exactly?
> 
> For that matter, how many of them are in base or standard packages?

I don't know.  Should anyone care?

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

Fine.  Just to please you, I'm running pdksh as /bin/sh.
I imagine that none of the other 6 people reading this thread
are using anything but ash or bash.

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

Do you have such little faith in the maintainers of those packages that
you imagine it will take them years to either fix or downgrade the bugs
on their own?

> 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

must violation -> serious bug -> rc

You disagree that all must violations are serious, or you think that all
non-serious must violations are typoes.

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

The same is true of all bugs, wouldn't you say?

> 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 didn't realize your question was about shells.

> I presume you mean compatability and portability of our scripts to other
> systems, or is there more to it than that?

I presume that the value of picking POSIX instead of some other standard
has to do with portability with other systems.  In addition, it makes
things easier for us, because certain shells aspire toward POSIX
compatibility.

Insofar as /bin/sh goes, I imagine few would say it needs to be
compatible with other systems.

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

I'll put that on my list.

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

You have a strange idea of "most":

bash echo: broken
shellutils echo: broken

ash echo: does it
pdksh echo: does it
zsh echo: does it

Are you counting c-shells?  Still, that's one either way.

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

SUSv3 recommends &&/|| over '-a/-o' on the grounds of portability and
security.

> Who's our primary audience here, Debian users or people who want to pull
> apart our packages and use them on Solaris systems?

That would be Debian users.

> Does "optimise for the common case" really ring that hollow?

Yes, it does.  bash is the common case, therefore all #!/bin/sh scripts
should be optimized for bash.  You can't optimize for bash and have all
the scripts still work in ash.  Maybe the common case is "ash or bash".
Maybe the common case is "Bourne shell".  Maybe the common case is
"near-POSIX-compliant shell".  Which case is optimal?

> That FHS is a release-critical issue, unlike, say bashims. Although
> certain parties think I'm being overly anal about that, too.

On what possible grounds should FHS-compliance be release-critical?  A
violation breaks absolutely nothing.

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

Sounds reasonable.

> 	(2) There's no benefit to anyone using a shell other than ash or
> 	    bash as /bin/sh on a Debian system.

No, you're being deliberately obtuse on this one.

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

Well, that's a little weak.  I imagine very few SUSv3 scripts will want
to echo "-n".
 
> 	(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)

Sounds reasonable.

> 	(5) Clint wants to remove the -n exception for echo, which
> 	    contradicts (rather than extends) POSIX.

Good.

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

Well, if you're going to continue to ignore claims potential benefits of
other shells as /bin/sh, and insist that users shouldn't have that
choice whether or not those benefits exist, then it might be difficult.


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