Bug#339955: Bug#513955: debian-policy: do not require /etc/init.d/*.sh scripts to be sourced
On Saturday 14 February 2009 14:01:40 Russ Allbery wrote: Kel Modderman k...@otaku42.de writes: It is the opinion of myself and Petter Reinholdtsen, maintainers of the sysvinit package, that the last sentence of §9.3.1 of policy is no longer relevant and should be removed: Also, if the script name ends in .sh, the script will be sourced in runlevel S rather than being run in a forked subprocess, but will be explicitly run by sh in all other runlevels. I went to write the patch for this, but I paused when I saw that the other part of this sentence (explicitly running such scripts with sh at other run levels) is implemented. The current /etc/init.d/rc runs the script directly if it doesn't end in .sh but runs it with sh if it does. That's not an interface that has much merit either, it would be nice if we didn't have to support it and we had the freedom to execute the scripts directly. At least on my system, all of the scripts ending in .sh have a proper #! line and are executable, so this wouldn't make any difference there, but I wanted to double-check first before also removing that since it appears to be implemented. I think all scripts in /etc/init.d/ must have a shebang line and be executable, and be able to be executed directly. Executing .sh scripts explicitly by sh is not something I see much value in supporting, Petter expressed similar sentiment when I poked him on IRC. Thanks, Kel. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#513955: debian-policy: do not require /etc/init.d/*.sh scripts to be sourced
Kel Modderman k...@otaku42.de writes: On Saturday 14 February 2009 14:01:40 Russ Allbery wrote: I went to write the patch for this, but I paused when I saw that the other part of this sentence (explicitly running such scripts with sh at other run levels) is implemented. The current /etc/init.d/rc runs the script directly if it doesn't end in .sh but runs it with sh if it does. That's not an interface that has much merit either, it would be nice if we didn't have to support it and we had the freedom to execute the scripts directly. Agreed. I just wanted to be sure that this was the intention. I think all scripts in /etc/init.d/ must have a shebang line and be executable, and be able to be executed directly. Executing .sh scripts explicitly by sh is not something I see much value in supporting, Petter expressed similar sentiment when I poked him on IRC. Good enough for me. This change will be in the next release of Policy. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#513955: [Pkg-sysvinit-devel] Bug#339955: Bug#513955: debian-policy: do not require /etc/init.d/*.sh scripts to be sourced
On Fri, 13 Feb 2009, Russ Allbery wrote: I went to write the patch for this, but I paused when I saw that the other part of this sentence (explicitly running such scripts with sh at other run levels) is implemented. The current /etc/init.d/rc runs the script directly if it doesn't end in .sh but runs it with sh if it does. At least on my system, all of the scripts ending in .sh have a proper #! line and are executable, so this wouldn't make any difference there, but I wanted to double-check first before also removing that since it appears to be implemented. Non-executable shell initscripts are NOT supported. While rc might handle them, invoke-rc.d will refuse to run them, and it also breaks the well-understood and standard call /etc/init.d/initscript action directly which everything under the sun expects to work. It is something left over from the ancient past that we can and should get rid of. At most, it deserves a note on the NEWS.Debian file, if that much. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#513955: debian-policy: do not require /etc/init.d/*.sh scripts to be sourced
Russ Allbery wrote: Kel Modderman k...@otaku42.de writes: It is the opinion of myself and Petter Reinholdtsen, maintainers of the sysvinit package, that the last sentence of §9.3.1 of policy is no longer relevant and should be removed: Also, if the script name ends in .sh, the script will be sourced in runlevel S rather than being run in a forked subprocess, but will be explicitly run by sh in all other runlevels. I went to write the patch for this, but I paused when I saw that the other part of this sentence (explicitly running such scripts with sh at other run levels) is implemented. The current /etc/init.d/rc runs the script directly if it doesn't end in .sh but runs it with sh if it does. As alternative, I propose not to use the suffix .sh: - now we change /will be sourced/could be sourced/ , with a footnote that deprecated such feature - we bugs package, to remove the suffix .sh - after most of the most important packages removed the .sh suffix, the policy remove the exception, maybe introducing a footnote which shortly explain the past rules (this will simplify the writing of rationale in the new doc) Rationale: users could be confused by the .sh suffix. At least on my system, all of the scripts ending in .sh have a proper #! line and are executable, so this wouldn't make any difference there, but I wanted to double-check first before also removing that since it appears to be implemented. hmm. All init.d script should be executable, with proper #! header. Sysadmin are used to manually /etc/init.d/foo stop|start|restart|reload So I don't understand your commentart. ciao cate ciao cate -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#339955: Bug#513955: debian-policy: do not require /etc/init.d/*.sh scripts to be sourced
On Mon, Feb 16, 2009 at 10:01:37AM +0100, Giacomo A. Catenazzi wrote: Russ Allbery wrote: Kel Modderman k...@otaku42.de writes: It is the opinion of myself and Petter Reinholdtsen, maintainers of the sysvinit package, that the last sentence of §9.3.1 of policy is no longer relevant and should be removed: Also, if the script name ends in .sh, the script will be sourced in runlevel S rather than being run in a forked subprocess, but will be explicitly run by sh in all other runlevels. I went to write the patch for this, but I paused when I saw that the other part of this sentence (explicitly running such scripts with sh at other run levels) is implemented. The current /etc/init.d/rc runs the script directly if it doesn't end in .sh but runs it with sh if it does. As alternative, I propose not to use the suffix .sh: - now we change /will be sourced/could be sourced/ , with a footnote that deprecated such feature - we bugs package, to remove the suffix .sh - after most of the most important packages removed the .sh suffix, the policy remove the exception, maybe introducing a footnote which shortly explain the past rules (this will simplify the writing of rationale in the new doc) Rationale: users could be confused by the .sh suffix. While I agree in general that the .sh suffix should not be mentionned unless it has a specific meaning, I am afraid that your proposal will be technically troublesome, because the file /etc/init.d/*.sh are conffiles and renaming conffiles is a pain. Since such files are critical at startup, I am afraid than an attempt to rename them will make the upgrade path to squeeze more fragile. At least on my system, all of the scripts ending in .sh have a proper #! line and are executable, so this wouldn't make any difference there, but I wanted to double-check first before also removing that since it appears to be implemented. hmm. All init.d script should be executable, with proper #! header. Sysadmin are used to manually /etc/init.d/foo stop|start|restart|reload So I don't understand your commentart. I think Russ point is that there is no reason for policy to mandate to run them with 'sh /etc/init.d/foo' if you can just run them directly as '/etc/init.d/foo', as you suggest. If we are going to remove Also, if the script name ends in .sh, the script will be sourced in runlevel S rather than being run in a forked subprocess, then we can just remove any difference in handling a script called /etc/init.d/foo.sh versus /etc/init.d/bar. Cheers, -- Bill. ballo...@debian.org Imagine a large red swirl here. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#513955: debian-policy: do not require /etc/init.d/*.sh scripts to be sourced
Kel Modderman k...@otaku42.de writes: It is the opinion of myself and Petter Reinholdtsen, maintainers of the sysvinit package, that the last sentence of §9.3.1 of policy is no longer relevant and should be removed: Also, if the script name ends in .sh, the script will be sourced in runlevel S rather than being run in a forked subprocess, but will be explicitly run by sh in all other runlevels. I went to write the patch for this, but I paused when I saw that the other part of this sentence (explicitly running such scripts with sh at other run levels) is implemented. The current /etc/init.d/rc runs the script directly if it doesn't end in .sh but runs it with sh if it does. At least on my system, all of the scripts ending in .sh have a proper #! line and are executable, so this wouldn't make any difference there, but I wanted to double-check first before also removing that since it appears to be implemented. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#513955: debian-policy: do not require /etc/init.d/*.sh scripts to be sourced
Hello Russ, Russ Allbery hat am Mon 02. Feb, 20:36 (-0800) geschrieben: Kel Modderman k...@otaku42.de writes: It is the opinion of myself and Petter Reinholdtsen, maintainers of the sysvinit package, that the last sentence of §9.3.1 of policy is no longer relevant and should be removed: Also, if the script name ends in .sh, the script will be sourced in runlevel S rather than being run in a forked subprocess, but will be explicitly run by sh in all other runlevels. The reasons for which it should be removed are: * /etc/init.d/rc has not supported this for an extremely long time, probably never, because the system would be unbootable due to .sh scripts calling 'exit' [0, 1]. Given this, I definitely agree. There's no point in having a statement like this in Policy when our core packages don't implement it and no one has apparently cared. I agree with you and second the proposal. As much as I like the idea to run scripts in the context of the rc process, I see no much value for packages and I as the administrator of a system can modify the rc script. I follow you that such a requirement generates more problems than it solves. Bye, Jörg. -- Prof. in der Mathematikvorlesung zu einem vergessenen φ in der Gleichung: „Klein‐φ macht auch Mist.“ signature.asc Description: Digital signature http://en.wikipedia.org/wiki/OpenPGP
Bug#339955: Bug#513955: debian-policy: do not require /etc/init.d/*.sh scripts to be sourced
Kel Modderman k...@otaku42.de writes: It is the opinion of myself and Petter Reinholdtsen, maintainers of the sysvinit package, that the last sentence of §9.3.1 of policy is no longer relevant and should be removed: Also, if the script name ends in .sh, the script will be sourced in runlevel S rather than being run in a forked subprocess, but will be explicitly run by sh in all other runlevels. The reasons for which it should be removed are: * /etc/init.d/rc has not supported this for an extremely long time, probably never, because the system would be unbootable due to .sh scripts calling 'exit' [0, 1]. Given this, I definitely agree. There's no point in having a statement like this in Policy when our core packages don't implement it and no one has apparently cared. Unless someone steps up to say that we should do the work to reimplement support for this interface (including fixing all the broken *.sh scripts we have now), I think it's obvious we should simply remove it. There's no need to specify things no one uses and clearly can do without. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#513955: debian-policy: do not require /etc/init.d/*.sh scripts to be sourced
Russ Allbery wrote: Kel Modderman k...@otaku42.de writes: It is the opinion of myself and Petter Reinholdtsen, maintainers of the sysvinit package, that the last sentence of §9.3.1 of policy is no longer relevant and should be removed: Also, if the script name ends in .sh, the script will be sourced in runlevel S rather than being run in a forked subprocess, but will be explicitly run by sh in all other runlevels. The reasons for which it should be removed are: * /etc/init.d/rc has not supported this for an extremely long time, probably never, because the system would be unbootable due to .sh scripts calling 'exit' [0, 1]. Given this, I definitely agree. There's no point in having a statement like this in Policy when our core packages don't implement it and no one has apparently cared. Unless someone steps up to say that we should do the work to reimplement support for this interface (including fixing all the broken *.sh scripts we have now), I think it's obvious we should simply remove it. There's no need to specify things no one uses and clearly can do without. I agree. BTW LSB doesn't have such special case, so such proposal will converge to LSB, which is also positive. ciao cate -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
