Re: Future of update-rc.d in wheezy+1
On Thu, Jun 28, 2012 at 10:52:23AM +0100, Roger Leigh wrote: On Thu, Jun 28, 2012 at 10:44:53AM +0200, Goswin von Brederlow wrote: The numbers specified for update-rc.d must be well ordered according to the dependencies specified in the LSB headers. That means that that update-rc.d could keep a record of the numbers specified and check that the numbers are valid even though sysv-rc/insserv then ignore them. While we could expend the time and effort to do this, I do have to question why. What would be the point of this? No one is using those numbers, so why retain them? It seems, to me, to be an entirely pointless waste of valuable developer time. And not just my time, but for every developer who would need to continue to test and validate the numbers for their scripts. We have dependencies for a reason, and the sequence numbers are now nothing more than a historical artifact. Well, I’m using file-rc on all my systems for many years. - „vi /etc/runlevel.conf” is easier than working with strange symlinks; - if I don’t want a service to start, I can replace „2,3,4,5” with „-”; - third-party software without Debian package doesn’t use update-rc.d; getting it to start is easier if I only have to edit one file (runlevel.conf); I have never used dependency based booting. - old systems had to many old init scripts without LSB headers, so the upgrade failed; - some software needs a database, but the database server may not be the same server, so the software can’t have a dependency on the database server; so I have to overwrite the dependency configuration in some way; - third-party software doesn’t have any LSB headers; IIRC the upgrade to dependency based booting doesn’t fail anymore if you have initscripts without LSB headers (they are now running at the end of the boot process), but for now I still don’t see any reason to change. Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | Public Keys: http://fsing.rootsland.net/~stse/keys.html | smime.p7s Description: S/MIME cryptographic signature
Re: Future of update-rc.d in wheezy+1
On 27.06.2012 11:13, Roger Leigh wrote: I'd like to suggest that we do the following in sysv-rc update-rc.d: - wheezy: silently drop start|stop sequence numbers and runlevels (this is already the case when using insserv, and we can remove the non-insserv codepaths) - wheezy+1: warn if these options are used - wheezy+2: remove support for the options and error out if used error out in dh_install or update-rc.d? And additionally, to add lintian warnings for use of these options, including when using dh_installinit. All in all, sounds reasonable. Please go ahead with this. It is seriously annoying making up random sequence numbers just to please dh_install/update-rc.d. Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: Future of update-rc.d in wheezy+1
On 01.07.2012 22:58, Michael Biebl wrote: On 27.06.2012 11:13, Roger Leigh wrote: - wheezy+2: remove support for the options and error out if used error out in dh_install or update-rc.d? ^ dh_installinit It is seriously annoying making up random sequence numbers just to please dh_install/update-rc.d. ^ dh_installinit -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: Future of update-rc.d in wheezy+1
On Sun, Jul 01, 2012 at 10:58:09PM +0200, Michael Biebl wrote: On 27.06.2012 11:13, Roger Leigh wrote: I'd like to suggest that we do the following in sysv-rc update-rc.d: - wheezy: silently drop start|stop sequence numbers and runlevels (this is already the case when using insserv, and we can remove the non-insserv codepaths) - wheezy+1: warn if these options are used - wheezy+2: remove support for the options and error out if used error out in dh_install or update-rc.d? dh_install initially, since it only breaks builds rather than upgrades. Maybe even for wheezy+1. I'll see about adding a lintian check before that point though. update-rc.d could just warn for wheezy+1, but won't actually use the options for anything (start and stop can just be synonymous with defaults), which will allow old scripts to continue working. And additionally, to add lintian warnings for use of these options, including when using dh_installinit. All in all, sounds reasonable. Please go ahead with this. It is seriously annoying making up random sequence numbers just to please dh_install/update-rc.d. I've added insserv support to file-rc this weekend, which was the only thing still using the sequence numbers. I'd like to get this in wheezy, even though it's after the freeze, since it means there will be zero users of the numbers in the wheezy-wheezy+1 upgrade, which will allow us to disable them immediately after the release of wheezy. (#539591) Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120701232244.gy9...@codelibre.net
Re: Future of update-rc.d in wheezy+1
On Sun, Jul 01, 2012 at 06:39:57PM +0200, Stephan Seitz wrote: On Thu, Jun 28, 2012 at 10:52:23AM +0100, Roger Leigh wrote: On Thu, Jun 28, 2012 at 10:44:53AM +0200, Goswin von Brederlow wrote: The numbers specified for update-rc.d must be well ordered according to the dependencies specified in the LSB headers. That means that that update-rc.d could keep a record of the numbers specified and check that the numbers are valid even though sysv-rc/insserv then ignore them. While we could expend the time and effort to do this, I do have to question why. What would be the point of this? No one is using those numbers, so why retain them? It seems, to me, to be an entirely pointless waste of valuable developer time. And not just my time, but for every developer who would need to continue to test and validate the numbers for their scripts. We have dependencies for a reason, and the sequence numbers are now nothing more than a historical artifact. Well, I’m using file-rc on all my systems for many years. - „vi /etc/runlevel.conf” is easier than working with strange symlinks; - if I don’t want a service to start, I can replace „2,3,4,5” with „-”; - third-party software without Debian package doesn’t use update-rc.d; getting it to start is easier if I only have to edit one file (runlevel.conf); No one messes with symlinks. We have update-rc.d for that for both sysv-rc and file-rc. For sysv-rc, insserv manages them for you, and in theory we could even get rid of them entirely and have the dependencies computed at runtime. We'd just need a mechanism for recording which scripts were disabled. When you edit runlevel.conf, you have to maintain the script ordering, by hand, using the sequence number field. This is (or is becoming) utterly broken, and is why we have dependency based booting nowadays. The numbers are computed automatically by insserv; this is far less error prone and much more flexible. I have never used dependency based booting. - old systems had to many old init scripts without LSB headers, so the upgrade failed; - some software needs a database, but the database server may not be the same server, so the software can’t have a dependency on the database server; so I have to overwrite the dependency configuration in some way; - third-party software doesn’t have any LSB headers; IIRC the upgrade to dependency based booting doesn’t fail anymore if you have initscripts without LSB headers (they are now running at the end of the boot process), but for now I still don’t see any reason to change. Given that it's been the default for quite a few years now, you really should try it. The sequence numbers are going away, so if there are problems with it that you need fixing, then they need indentifying and reporting. Editing the LSB headers in the scripts to do stuff like not depend on a local server is not exactly rocket science. And we have Should-Start rather than Required-Start for exactly this situation--if you found a buggy LSB dependency, for goodness sake report it and get it fixed, rather than perpetuating the awful static sequence numbers. Dependency based boot works, and works well. There is no reason to continue to use file-rc. [I spent the weekend adding insserv support to file-rc. But the consequence of computing the sequence numbers automatically is that it no longer makes sense to edit runlevel.conf by hand--adding or removing an init script could recompute the sequence numbers of many scripts. runlevel.conf is essentially just marking scripts as enabled if present, disabled if absent.] Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120701233720.gz9...@codelibre.net
Re: [Pkg-sysvinit-devel] Future of update-rc.d in wheezy+1
tags 539591 + patch thanks On Thu, Jun 28, 2012 at 02:40:18PM +0100, Roger Leigh wrote: On Thu, Jun 28, 2012 at 08:02:33AM +0200, Alexander Wirt wrote: On Wed, 27 Jun 2012, Roger Leigh wrote: On Wed, Jun 27, 2012 at 04:39:38PM +0200, Bernd Zeimetz wrote: On 06/27/2012 03:46 PM, Alexander Wirt wrote: On Wed, 27 Jun 2012, Paul Wise wrote: On Wed, Jun 27, 2012 at 6:27 PM, Petter Reinholdtsen wrote: Yes. See URL: http://bugs.debian.org/539591 , URL: http://bugs.debian.org/573004 and the source of insserv, where a patch to do this was created and included by Kel. The patch has been available for more than two years. Hmm, no upload in those two years either. Is file-rc still maintained at all? It is. But more or less in no-new-features mode. Implementing the insserv stuff is wishlist for me. Even when I now get forced into it. I don't think there's any question of forcing, but encouraging file-rc to retain compatibility with the init scripts being used by the distribution. It looks like the patches are there, they just need testing. If file-rc could have this in place for wheezy, that would be highly desirable, so that we can work on deprecating runlevel sequence numbers in wheezy+1. Nope, there is an experimental patch for insserv to print out sequence numbers, to get this working I first have to build my own insserv. And the whole file-rc part is - beside of some ideas in my mind - missing. So the insserv patch is already present, it just needs enabling. So 10 mins tops to download and rebuild. I never saw a followup in the bug above--does the output format suit your needs? If it does, please say so. It could potentially be enabled and uploaded today or tomorrow. The patch works just fine. I retested it this evening. Short example: % insserv -s | egrep '(postgresql|cron|procps|sudo)$' K:02:0 1 6:postgresql K:01:0 1 6:anacron S:02:2 3 4 5:postgresql S:02:2 3 4 5:anacron S:02:2 3 4 5:cron S:01:2 3 4 5:sudo S:13:S:procps One you have the dependency info, can't you just query that in your update-rc.d implementation to override the defaults provided to update-rd.d? Does it require anything more complex than that? The following patch implements this behaviour. While the insserv parsing logic has been tested, it's not been tested for upgrades or whether the whole script works correctly. - it needs a Depends on insserv (= $version_with_-s) == this needs your feedback so it can be uploaded. - the preinst could be simplified to just use update-rc.d $script -f defaults if this is sufficient to update the sequence numbers in the configuration. This probably needs running in the postinst TBH. - this just replaces the defaults and user-provided start and stop arguments with those provided by insserv. Other than that, there are no changes to anything else. - You might need to retain support for the old-style logic so that if other scripts call update-rc.d in the gap between unpacking and running the postinst, it won't fail. Just back out the deletions and run those blocks only if insserv didn't run or didn't find any matches, which are a trivial addition to the script. While this patch is just a proof a concept, this should be pretty much all you need. It just needs checking and testing by someone with file-rc expertise. If this could be done in the very near future, then that would be great. Please do provide some feedback on whether insserv -s is sufficient for your needs. Thanks, Roger diff -urN file-rc-0.8.12.original/debian/changelog file-rc-0.8.13/debian/changelog --- file-rc-0.8.12.original/debian/changelog2010-04-07 20:30:54.0 +0100 +++ file-rc-0.8.13/debian/changelog 2012-06-29 20:00:01.917474582 +0100 @@ -1,3 +1,10 @@ +file-rc (0.8.13) UNRELEASED; urgency=low + + * Use insserv for runlevel defaults rather than the arguments +provided to update-rc.d. + + -- Roger Leigh rle...@debian.org Fri, 29 Jun 2012 19:59:06 +0100 + file-rc (0.8.12) unstable; urgency=low * New maintainer (Closes: #539609) diff -urN file-rc-0.8.12.original/debian/preinst file-rc-0.8.13/debian/preinst --- file-rc-0.8.12.original/debian/preinst 2010-04-07 20:30:54.0 +0100 +++ file-rc-0.8.13/debian/preinst 2012-06-29 20:06:18.739474331 +0100 @@ -14,6 +14,8 @@ # for details, see http://www.debian.org/doc/debian-policy/ or # the debian-policy package +# Make sure insserv is in path +PATH=/sbin:$PATH case $1 in install) @@ -64,6 +66,19 @@ dpkg-divert --package file-rc --remove \ --divert /etc/init.d/rcS.links /etc/init.d/rcS fi + + if [ $2 != ] dpkg --compare-versions $2 lt 0.8.13 + then + for script in /etc/init.d/* + do + if [ -x $script ] + then + script=$(basename $script) +
Re: [Pkg-sysvinit-devel] Future of update-rc.d in wheezy+1
On Wed, 27 Jun 2012, Roger Leigh wrote: On Wed, Jun 27, 2012 at 04:39:38PM +0200, Bernd Zeimetz wrote: On 06/27/2012 03:46 PM, Alexander Wirt wrote: On Wed, 27 Jun 2012, Paul Wise wrote: On Wed, Jun 27, 2012 at 6:27 PM, Petter Reinholdtsen wrote: Yes. See URL: http://bugs.debian.org/539591 , URL: http://bugs.debian.org/573004 and the source of insserv, where a patch to do this was created and included by Kel. The patch has been available for more than two years. Hmm, no upload in those two years either. Is file-rc still maintained at all? It is. But more or less in no-new-features mode. Implementing the insserv stuff is wishlist for me. Even when I now get forced into it. I don't think there's any question of forcing, but encouraging file-rc to retain compatibility with the init scripts being used by the distribution. It looks like the patches are there, they just need testing. If file-rc could have this in place for wheezy, that would be highly desirable, so that we can work on deprecating runlevel sequence numbers in wheezy+1. Nope, there is an experimental patch for insserv to print out sequence numbers, to get this working I first have to build my own insserv. And the whole file-rc part is - beside of some ideas in my mind - missing. So its unlikely to get this working unless insserv (for the patch) and file-rc get a freeze exception. Alex -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120628060233.gf6...@snow-crash.org
Re: Future of update-rc.d in wheezy+1
Roger Leigh rle...@codelibre.net writes: Hi folks, I'd just like to briefly discuss potential plans for update-rc.d in wheezy+1, and how this might impact on file-rc and sysv-rc. sysv-rc has defaulted to using LSB header dependencies and insserv for a few years now. The last few releases require you to enable insserv to upgrade, and the pending upload just does this automatically. The result is that all wheezy users of sysv-rc will be using dependency-based boot. This means that the runlevels and sequence numbers passed as arguments to update-rc.d will never be used; they will just get silently discarded. The main problem as I see it is that these numbers are going to bitrot badly--they aren't being tested, while the dependency information in the header is being used by everyone. I'd like to suggest that we do the following in sysv-rc update-rc.d: - wheezy: silently drop start|stop sequence numbers and runlevels (this is already the case when using insserv, and we can remove the non-insserv codepaths) - wheezy+1: warn if these options are used - wheezy+2: remove support for the options and error out if used And additionally, to add lintian warnings for use of these options, including when using dh_installinit. The main problem that I can see is file-rc is currently still dependent upon the sequence numbers and runlevel information. Would it be possible for file-rc to also add support for dependencies? Given that the static boot ordering is quite dead at this point, it would be very helpful to know what's possible here. Could it use insserv to do the dependency graph and then just consume the makefile-style dependency list? Regards, Roger You say the numbers are going to bitrot, which I totaly agree. But that could be prevented. The numbers specified for update-rc.d must be well ordered according to the dependencies specified in the LSB headers. That means that that update-rc.d could keep a record of the numbers specified and check that the numbers are valid even though sysv-rc/insserv then ignore them. This check could also be done as archive wide check using piuparts or something. Doesn't have to be done on every users systems. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/871ukzn7ui.fsf@frosties.localnet
Re: Future of update-rc.d in wheezy+1
On Thu, Jun 28, 2012 at 10:44:53AM +0200, Goswin von Brederlow wrote: Roger Leigh rle...@codelibre.net writes: This means that the runlevels and sequence numbers passed as arguments to update-rc.d will never be used; they will just get silently discarded. The main problem as I see it is that these numbers are going to bitrot badly--they aren't being tested, while the dependency information in the header is being used by everyone. You say the numbers are going to bitrot, which I totaly agree. But that could be prevented. The numbers specified for update-rc.d must be well ordered according to the dependencies specified in the LSB headers. That means that that update-rc.d could keep a record of the numbers specified and check that the numbers are valid even though sysv-rc/insserv then ignore them. While we could expend the time and effort to do this, I do have to question why. What would be the point of this? No one is using those numbers, so why retain them? It seems, to me, to be an entirely pointless waste of valuable developer time. And not just my time, but for every developer who would need to continue to test and validate the numbers for their scripts. We have dependencies for a reason, and the sequence numbers are now nothing more than a historical artifact. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120628095223.gs9...@codelibre.net
Re: Future of update-rc.d in wheezy+1
On Jun 28, Roger Leigh rle...@codelibre.net wrote: While we could expend the time and effort to do this, I do have to question why. What would be the point of this? No one is using those numbers, so why retain them? Agreed. -- ciao, Marco signature.asc Description: Digital signature
Re: [Pkg-sysvinit-devel] Future of update-rc.d in wheezy+1
On Thu, Jun 28, 2012 at 08:02:33AM +0200, Alexander Wirt wrote: On Wed, 27 Jun 2012, Roger Leigh wrote: On Wed, Jun 27, 2012 at 04:39:38PM +0200, Bernd Zeimetz wrote: On 06/27/2012 03:46 PM, Alexander Wirt wrote: On Wed, 27 Jun 2012, Paul Wise wrote: On Wed, Jun 27, 2012 at 6:27 PM, Petter Reinholdtsen wrote: Yes. See URL: http://bugs.debian.org/539591 , URL: http://bugs.debian.org/573004 and the source of insserv, where a patch to do this was created and included by Kel. The patch has been available for more than two years. Hmm, no upload in those two years either. Is file-rc still maintained at all? It is. But more or less in no-new-features mode. Implementing the insserv stuff is wishlist for me. Even when I now get forced into it. I don't think there's any question of forcing, but encouraging file-rc to retain compatibility with the init scripts being used by the distribution. It looks like the patches are there, they just need testing. If file-rc could have this in place for wheezy, that would be highly desirable, so that we can work on deprecating runlevel sequence numbers in wheezy+1. Nope, there is an experimental patch for insserv to print out sequence numbers, to get this working I first have to build my own insserv. And the whole file-rc part is - beside of some ideas in my mind - missing. So the insserv patch is already present, it just needs enabling. So 10 mins tops to download and rebuild. I never saw a followup in the bug above--does the output format suit your needs? If it does, please say so. It could potentially be enabled and uploaded today or tomorrow. One you have the dependency info, can't you just query that in your update-rc.d implementation to override the defaults provided to update-rd.d? Does it require anything more complex than that? Example: If you are invoked with update-rc.d cron start 89 2 3 4 5 . then you run insserv -s | grep ':cron$' == K:01:0 1 6:cron S:04:2 3 4 5:cron So you just treat that as equivalent to update-rc.d cron start 04 2 3 4 5 . stop 01 0 1 6 . and AFAICS you're done. i.e. you're just getting the runlevel info from insserv, rather than from the command-line options. Should be quite straightforward. So its unlikely to get this working unless insserv (for the patch) and file-rc get a freeze exception. I'm sure we can ask for one. If it's not done for wheezy, that will cause problems in removing sequence numbers in wheezy+1, since upgrades will then cause breakage for file-rc users (either because they are bitrotted, or because they are no longer present). I would prefer that this not drag out over *three* stable releases--since this has been really needed since before squeeze, and no action has been taken to date in file-rc. It's really not in our users' interest to have file-rc using increasingly buggy sequence numbers. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120628134018.gw9...@codelibre.net
Future of update-rc.d in wheezy+1
Hi folks, I'd just like to briefly discuss potential plans for update-rc.d in wheezy+1, and how this might impact on file-rc and sysv-rc. sysv-rc has defaulted to using LSB header dependencies and insserv for a few years now. The last few releases require you to enable insserv to upgrade, and the pending upload just does this automatically. The result is that all wheezy users of sysv-rc will be using dependency-based boot. This means that the runlevels and sequence numbers passed as arguments to update-rc.d will never be used; they will just get silently discarded. The main problem as I see it is that these numbers are going to bitrot badly--they aren't being tested, while the dependency information in the header is being used by everyone. I'd like to suggest that we do the following in sysv-rc update-rc.d: - wheezy: silently drop start|stop sequence numbers and runlevels (this is already the case when using insserv, and we can remove the non-insserv codepaths) - wheezy+1: warn if these options are used - wheezy+2: remove support for the options and error out if used And additionally, to add lintian warnings for use of these options, including when using dh_installinit. The main problem that I can see is file-rc is currently still dependent upon the sequence numbers and runlevel information. Would it be possible for file-rc to also add support for dependencies? Given that the static boot ordering is quite dead at this point, it would be very helpful to know what's possible here. Could it use insserv to do the dependency graph and then just consume the makefile-style dependency list? Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120627091329.gj9...@codelibre.net
Re: [Pkg-sysvinit-devel] Future of update-rc.d in wheezy+1
[Roger Leigh] Could [file-rc] use insserv to do the dependency graph and then just consume the makefile-style dependency list? Yes. See URL: http://bugs.debian.org/539591 , URL: http://bugs.debian.org/573004 and the source of insserv, where a patch to do this was created and included by Kel. The patch has been available for more than two years. -- Happy hacking Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120627092719.gb20...@login2.uio.no
Re: [Pkg-sysvinit-devel] Future of update-rc.d in wheezy+1
On Wed, Jun 27, 2012 at 6:27 PM, Petter Reinholdtsen wrote: Yes. See URL: http://bugs.debian.org/539591 , URL: http://bugs.debian.org/573004 and the source of insserv, where a patch to do this was created and included by Kel. The patch has been available for more than two years. Hmm, no upload in those two years either. Is file-rc still maintained at all? -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caktje6foqhovi6zae6yx-cbol81zlxvkujzxcgghvpmntga...@mail.gmail.com
Re: [Pkg-sysvinit-devel] Future of update-rc.d in wheezy+1
On Wed, 27 Jun 2012, Paul Wise wrote: On Wed, Jun 27, 2012 at 6:27 PM, Petter Reinholdtsen wrote: Yes. See URL: http://bugs.debian.org/539591 , URL: http://bugs.debian.org/573004 and the source of insserv, where a patch to do this was created and included by Kel. The patch has been available for more than two years. Hmm, no upload in those two years either. Is file-rc still maintained at all? It is. But more or less in no-new-features mode. Implementing the insserv stuff is wishlist for me. Even when I now get forced into it. Alex -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120627134633.gc6...@snow-crash.org
Re: [Pkg-sysvinit-devel] Future of update-rc.d in wheezy+1
On 06/27/2012 03:46 PM, Alexander Wirt wrote: On Wed, 27 Jun 2012, Paul Wise wrote: On Wed, Jun 27, 2012 at 6:27 PM, Petter Reinholdtsen wrote: Yes. See URL: http://bugs.debian.org/539591 , URL: http://bugs.debian.org/573004 and the source of insserv, where a patch to do this was created and included by Kel. The patch has been available for more than two years. Hmm, no upload in those two years either. Is file-rc still maintained at all? It is. But more or less in no-new-features mode. Implementing the insserv stuff is wishlist for me. Even when I now get forced into it. So might be this could avoided if we switch to something more modern like openrc as discussed some weeks ago here - I think the main reason file-rc edxists is because its much more easy to maintain than all the other crap^Winit systems (including insserv) floating around. -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4feb1b2a.3080...@bzed.de
Re: [Pkg-sysvinit-devel] Future of update-rc.d in wheezy+1
On Wed, Jun 27, 2012 at 04:39:38PM +0200, Bernd Zeimetz wrote: On 06/27/2012 03:46 PM, Alexander Wirt wrote: On Wed, 27 Jun 2012, Paul Wise wrote: On Wed, Jun 27, 2012 at 6:27 PM, Petter Reinholdtsen wrote: Yes. See URL: http://bugs.debian.org/539591 , URL: http://bugs.debian.org/573004 and the source of insserv, where a patch to do this was created and included by Kel. The patch has been available for more than two years. Hmm, no upload in those two years either. Is file-rc still maintained at all? It is. But more or less in no-new-features mode. Implementing the insserv stuff is wishlist for me. Even when I now get forced into it. I don't think there's any question of forcing, but encouraging file-rc to retain compatibility with the init scripts being used by the distribution. It looks like the patches are there, they just need testing. If file-rc could have this in place for wheezy, that would be highly desirable, so that we can work on deprecating runlevel sequence numbers in wheezy+1. So might be this could avoided if we switch to something more modern like openrc as discussed some weeks ago here - I think the main reason file-rc edxists is because its much more easy to maintain than all the other crap^Winit systems (including insserv) floating around. The openrc runscript format is certainly a bit nicer than the LSB header, but at the same time has some disadvantages. With the LSB header/insserv setup, we can read all the headers and have a dependency graph for all the scripts. But when you run a script by hand, or with invoke-rc.d, it can't satisfy dependencies at that point--it's only at the level of /etc/init.d/rc for runlevel changes. OpenRC OTOH has no global view but can resolve dependencies iteratively when running a script directly. Having both would be nice, which is what systemd/upstart give us. I'm still following OpenRC stuff, though I've not had time to get involved directly yet. The main point preventing us adopting it is lack of support for LSB dependencies, which would make upgrades rather painful. We could possibly address this by autogeneration of runscript wrappers for LSB scripts. Ideally, I'd like for OpenRC to gain a high level dependency graph view of the system, but it doesn't look like this is a design that would be particularly popular with OpenRC upstream. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120627215404.gn9...@codelibre.net
