Bug#1051371: debian-policy: stop referring to legacy filesystem paths for script interpreters
On Fri, 8 Sept 2023 at 05:22, Russ Allbery wrote: > > Luca Boccassi writes: > > > And I am more than a bit sad that sensible, clear-cut, binding and > > already-implemented decisions taken by our constitutional bodies get > > constantly second-guessed and belittled because of an irrational > > attachment to inconsequential accidents of history. But what can we do, > > we'll just have to be sad together, I guess. > > > Aside from that, in the future please avoid using the word 'minorities' > > when talking about silly things such as liking or disliking symlinks, as > > in common English it is used to refer to much more serious matters. > > Okay, stop. We are not going to have a Policy conversation like this. > Nothing about this discussion style helps in making a good decision. > > Luca, you have asked repeatedly what you can do to advance the status of > your open Policy bugs. Most of the answer to that question is that a lot > of it is outside of your control; I've been having a spectacularly > annoying summer in a bunch of minor ways and, frankly, simply haven't done > much of anything I'm responsible for in Debian. But the most helpful > thing that you could possibly do would be to stop being utterly > emotionally exhausting to deal with. I hope you will fare better in autumn, and take all the time you need. If I inquire about status on the other open bugs is only because I am unsure of whether I have missed something on my side, and want to double check that nobody is waiting on new revisions or so, because I find it hard to track things in long email threads, and I easily miss stuff, especially as when I asked if I missed something, someone else said "Yes, Russ posted some comments on your most recent revision, I believe.", but I couldn't find it. I wouldn't have thought that sending a reply with "Anything I can do to unblock this?" once a month or so would be classed as abusive, but given it exhausts you, I'll stop and just hope I got everything right as-is. > Case in point: now I'm writing this email message rather than doing any of > the other things that I am quite sure you would rather that I be doing and > that you would consider a much higher priority. > > In this bug, about a point that from the Policy perspective is mostly not > even normative, which appears to partly be a bug report against Lintian by > proxy (the Policy Editors do not maintain Lintian), you started at an > emotional level of eight out of ten before anyone even disagreed with you. > Let me quote the start of this bug: > > I heard many times the policy maintainers mention something along the > lines of 'policy should not be a hammer to beat other maintainers > with'. Today I saw policy being used to force a maintainer to re-add > support for the deprecated and unsupported split-usr filesystem > layout, as 'policy only mentions /bin/sh, not /usr/bin/sh'. > > So let's update the policy to refer to modern and supported filesystem > paths as adopted by Debian de-facto and de-jure, and stop other > maintainers from getting beaten with it. > > So right from the first message, you're saying that the goal of this > proposal is to stop other people from doing something socially you don't > like that Policy doesn't even tell them to do. And you're using phrasing > that you know is loaded and contentious and that you know the people > you've been arguing with all over Debian will disagree with. No. The point of this proposal is to fix something that is self-evidently unclear - non-normative (as I've been told, I thought it was normative when I opened the bug) language being used as if it were normative, both by Lintian (yes, the issue has been raised separately and a fix provided) and by bug reporters. Given, again, I've been told many times (I believe by yourself, too) that policy should not be used as a tool to bash developers with, and given I have witnessed precisely that the other day, I hence decided to spend some of my time to try and fix that. As already discussed earlier on this thread, I am fine with changing the wording of the patch however it fits best, as long as it improves clarity for this purpose. > I have no idea why. Because you like making them mad? Because you're mad > and you want to keep rubbing in their face the fact you disagree with > them? Maybe you think this is your strongest argument? (It is not.) > > This is pretty much guaranteed to turn the bug into a fight regardless of > its technical merits, because this presentation essentially says that > you're spoiling for a fight and want someone to attack you. > > I cannot remember the last time I have seen someone who is this unwilling > to win an argument. It's driving me nuts. You are winning your technical > arguments in Debian! The technical design that you support is being > implemented because you and others have convinced people that it is a good > idea, even though some people are very upset about this! T
Bug#1051371: debian-policy: stop referring to legacy filesystem paths for script interpreters
> "Luca" == Luca Boccassi writes: Luca> Secondly, and less importantly, while I appreciate it's not Luca> how you handle policy changes, the way the rest of the Luca> distribution works is by 'building consensus' on mailing Luca> lists. Now I don't particularly like it, but it is what it Luca> is. And that means if somebody comes up with the most Luca> egregious nonsense like, to pick a completely fictional Luca> example, "hey folks, usr-merge broke docker, rsync and Luca> ansible, we need to revert it", and it is left unchallenged, Luca> then it becomes doxa. So it has to be challenged. Every Luca> time. After half a decade, you don't think _that_ is Luca> exhausting? Thanks for sharing this. I understand what you've been doing a lot better now. And if it is actually true that you need to challenge these assertions every time, your behavior makes more sense to me. However, it's been my experience that challenging these assertions every time is unnecessary. It actually makes it harder to judge consensus and keeps discussions alive longer than they need to. I actually think that there are cases where if you had said less, a consensus you would have liked just fine would have emerged faster than has happened. Often when someone says something rediculous in a consensus discussion it is best to let it fall into a void of silence. Challenging it can sometimes just give it energy. I would be very open to helping you (or anyone) explore how to work more efficiently in a consensus environment and how to espace from a consensus discussion when consensus is the wrong tool. I realized that I focused a lot on consensus during my term as DPL. A lot of that was that I was hoping to help people explore how to approach consensus discussions better (and because it was the right tool for some of those discussions). But there are a lot of discussions where consensus is the wrong tool. And now that we've leveled up how we approach consensus discussions, perhaps we should level up how not to have them:-) signature.asc Description: PGP signature
Processed: Re: Bug#1051371: debian-policy: stop referring to legacy filesystem paths for script interpreters
Processing control commands: > retitle -1 debian-policy: stop referring to specific paths in scripts shebang > examples Bug #1051371 [debian-policy] debian-policy: stop referring to legacy filesystem paths for script interpreters Changed Bug title to 'debian-policy: stop referring to specific paths in scripts shebang examples' from 'debian-policy: stop referring to legacy filesystem paths for script interpreters'. -- 1051371: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1051371 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1051371: debian-policy: stop referring to legacy filesystem paths for script interpreters
Control: retitle -1 debian-policy: stop referring to specific paths in scripts shebang examples On Thu, 7 Sep 2023 08:09:12 +0200 Helmut Grohne wrote: > Would you agree to repurpose this bug to propose the former change? > While my variant is weaker, it still prevents people from using policy > to require supporting split-/usr. I have rewritten the patch and the commit message. Now it simply removes the full paths where it is not necessary, as the text simply talks about the different types of interpreters, and in two occasions where a shebang is specified, a note is added to mention that other valid paths are also acceptable (without saying what they are), taking in both your and Sam's suggestions as I've understood them. This thus doesn't encourage nor suggest any changes, but simply removes the ambiguity over what is and is not allowed by norm. Does this look more amenable? From Mon Sep 17 00:00:00 2001 From: Luca Boccassi Date: Wed, 6 Sep 2023 22:41:58 +0100 Subject: [PATCH] Stop referring to specific paths in scripts shebang examples These are being mistaken for normative languages, but they are just examples. Remove full paths where not needed, and specify that other valid paths (without mentioning them explicitly) are also acceptable in other places. --- policy/ch-files.rst | 20 +++- 1 file changed, 11 insertions(+), 9 deletions(-) diff --git a/policy/ch-files.rst b/policy/ch-files.rst index b34c183..593d586 100644 --- a/policy/ch-files.rst +++ b/policy/ch-files.rst @@ -211,8 +211,8 @@ may instead be easier to check the exit status of commands directly. See Every script should use ``set -e`` or check the exit status of *every* command. -Scripts may assume that ``/bin/sh`` implements the POSIX.1-2017 Shell Command -Language [#]_ plus the following additional features not mandated by +Scripts may assume that the ``sh`` executable implements the POSIX.1-2017 Shell +Command Language [#]_ plus the following additional features not mandated by POSIX.1-2017.. [#]_ - ``echo -n``, if implemented as a shell built-in, must not generate a @@ -248,16 +248,16 @@ POSIX.1-2017.. [#]_ If a shell script requires non-POSIX.1-2017 features from the shell interpreter other than those listed above, 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``). +in the first line of the script (e.g., ``#!/bin/bash`` or other valid paths) +and the package must depend on the package providing the shell (unless the shell +package is marked "Essential", as in the case of ``bash``). You may wish to restrict your script to POSIX.1-2017 features plus the above -set when possible so that it may use ``/bin/sh`` as its interpreter. +set when possible so that it may use ``sh`` as its interpreter. Checking your script with ``checkbashisms`` from the devscripts package or running your script with an alternate shell such as ``posh`` may help uncover violations of the above requirements. If in doubt whether a -script complies with these requirements, use ``/bin/bash``. +script complies with these requirements, use ``bash``. Perl scripts should check for errors when making any system calls, including ``open``, ``print``, ``close``, ``rename`` and ``system``. @@ -266,7 +266,9 @@ including ``open``, ``print``, ``close``, ``rename`` and ``system``. Programming Considered Harmful*, one of the ``comp.unix.*`` FAQs, which can be found at http://www.faqs.org/faqs/unix-faq/shell/csh-whynot/. If an upstream package comes with ``csh`` scripts then you must make sure -that they start with ``#!/bin/csh`` and make your package depend on the +that they start with the path of a csh interpreter, such as ``#!/bin/csh`` or +other valid paths, and make your package depend on the + ``c-shell`` virtual package. Any scripts which create files in world-writeable directories (e.g., in @@ -780,7 +782,7 @@ restricted to ASCII when it is possible to do so. .. [#] These features are in widespread use in the Linux community and are implemented in all of bash, dash, and ksh, the most common shells - users may wish to use as ``/bin/sh``. + users may wish to use as ``sh``. .. [#] This is necessary to allow top-level directories to be symlinks. If signature.asc Description: This is a digitally signed message part
