On Thu, 2014-10-02 at 20:43 -0700, Russ Allbery wrote: > A lot of people miss this about Policy 10.4. People seem to think that > Policy 10.4 is about requirements for shell scripts. But it's just as > much a standard for /bin/sh. You wrote it, so I guess you get to say what it means. But if you hadn't said so just now, I'd be using the "People"'s interpretation rather than yours. 10.4 is after all titled "Scripts", not "a sh language definition" or some such. Where it does define the shell language, it does so in in this context: "Scripts may assume that /bin/sh implements ...". So to me it is addressing itself to script writers, not sh language designers, and to extent it describe the the shell language standard is does to purely to inform the script writers what environment they can expect when they use "#!/bin/sh". > This was important when we were debating switching from bash to something > else, and needed to be clear about what behavior the rest of the > archive could expect /bin/sh to always satisfy. I looks to me like you are re-writing history. Right back in the 2.1.3.2 policy was pretty much what it was now. "#!/bin/sh" scripts had to be POSIX - albeit with less extensions than we allow today. If policy was so good at informing the debate about what "#!/bin/sh" scripts did, I'd be surprised there was much in the way of a debate. You could have switched to any shell that implemented the POSIX subset with very little pain. So this statement of yours: "we ... needed to be clear about what behavior the rest of the archive could expect /bin/sh to always satisfy" is puzzling, because there was pain. Everyone knew what /bin/sh did - it was defined in the bash man page. Since bashism's worked just fine, and evidently regardless of what policy said no one cared whether you used bash'ism or not so they were used with gay abandon. If as you suggest Debian relied on policy for a clear description of how /bin/sh scripts behaved, it was in for a rude shock. It didn't of course. Debian got the clear description it needed by writing automated checkers like checkbashism, followed threats to change /bin/sh away from /bin/bash, mass bug filings and finally in 2011 doing it. I am not criticising any part of this process. Standardising its shell language was huge undertaking for Debian, and pull it off almost without a hitch. It's the sort of thing that makes me proud of the project. What I am questioning is your assertion that policy that wasn't verified let alone enforced was somehow key to it. > I think people often don't realize what Policy is actually about, or what > it can (and can't!) accomplish. Policy is more a way for us to coordinate > our work and agree on what we're actually talking about than an enforced > set of rules that are followed. Again, you've lost me. Yes, policy that is followed and policed is very useful. It is very nice have man pages for almost everything. For me its essential I can rely on Debian's copyright policing. But to use this example again, you are saying the agreeing that "#!/bin/sh" scripts shall be POSIX shell scripts, and then largely ignoring it for 10 years because it is unverifiable was helpful to the project? I don't see how it saved anyone any time. > So yes, there's a lot of Policy that is ignored in practice. You can take > various attitudes towards that. You can view that as meaning Policy is > (at least partly) worthless because we're not enforcing it. Or you can > decide that Policy is more aspirational than descriptive. Or you can > focus on the change Policy has helped make happen. I think all those > viewpoints are accurate to a degree. OK, but realise you are making life hard for some of us here. Perhaps you, as one of the policy author's know what bits are hard and fast rules and which bits are purely aspirational. I don't. I guess if we less knowledgeable folk finding ourselves disagreeing with some policy, we can try assuming it's aspirational and ignore it. Yes, it made me cringe to write that. But you are telling me it is the way Debian works now. And I get the impression you think this is a good thing. > As bad as you think the compliance with Policy 10.4 is right now, I > guarantee that the prospects of being able to use something else as > /bin/sh would be way worse if we did what you suggest. Ah! And here we is our fundamental point of difference. It is beyond me how you could think that could be so. So much so that I'm doubting my comprehension abilities. I do have this right - the goal is to ensure "#!/bin/sh" scripts use a standardised subset of the shell languages out there? That way should a user change a different /bin/sh, he can be reasonably sure it will work if implements this well defined subset. (And yes, I acknowledge the subset is well defined in the current policy - well done.) To achieve that end you are proposing all we do is ask developers nicely to use that subset. The alternative I am proposing is to link /bin/sh to a program that implements just that subset (which it seems posh does), so their script bugs out if the policy is broken. And you are telling me you guarantee that the prospects of this working are better under your proposal than mine? >> Which is to say it should be obvious what you have to do to comply, >> it should be automatically verifiable you have complied, > > This is a lovely idea that has very little relationship to reality and > has not had much relationship to reality for as long as I've been > involved in Debian. It's surprising to see a lintian contributor say he thinks automatic verification and subsequent enforcement aren't worth much. Do you really think that? Anyway, even if it does not have much relationship to your reality, it sure has a relationship to mine, and mostly because of lintian. A few weeks ago I was forced to change something in a package in a way I strongly disagree with. It was noticed because of lintian (maybe one of your checks?), and later enforced by the FTP masters.
Attachment:
signature.asc
Description: This is a digitally signed message part