Bug#727708: package to change init systems
Ian Jackson ijack...@chiark.greenend.org.uk writes: Yes. I would still prefer to see something like that. I don't remember exactly what the objections were and I'm very very tired now but perhaps something like We expect that Debian will continue to support mkultiple init systems for the foreseeable future. would be acceptable to everyone ? I can't remember what the objections were to my previous wording. Or some other phrasing. I've been trying to avoid making decisions now about what happens beyond jessie, but I would not object to including that text since I think it's true for at least some values of support. Bdale pgpbcASx5jAnp.pgp Description: PGP signature
Bug#727708: package to change init systems
On Mon, Feb 03, 2014 at 07:45:19AM -0700, Bdale Garbee wrote: Ian Jackson ijack...@chiark.greenend.org.uk writes: Yes. I would still prefer to see something like that. I don't remember exactly what the objections were and I'm very very tired now but perhaps something like We expect that Debian will continue to support mkultiple init systems for the foreseeable future. would be acceptable to everyone ? I can't remember what the objections were to my previous wording. Or some other phrasing. I've been trying to avoid making decisions now about what happens beyond jessie, but I would not object to including that text since I think it's true for at least some values of support. This discussion started since the Software outside of an init system's implementation may not require a specific init system to be pid 1, although degraded operation is tolerable. in the L rider was interpreted by Russ as being valid forever, while I read the whole resolution text (including this part) as only being valid for jessie. Does a TC vote for this strict rule in the L rider make it binding only for jessie, or forever? This is the important question here. I am pretty sure the TC will anyway have to debate and decide on the init system(s) for jessie+1 in 1-2 years. Note that if a GR would re-affirm the TC decision, then a new GR might be needed to change a T/L rider decision if it is not limted to jessie. Bdale cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140203150616.ga26...@bunk.dyndns.info
Bug#727708: package to change init systems
Bdale Garbee writes (Bug#727708: package to change init systems): I've been trying to avoid making decisions now about what happens beyond jessie, but I would not object to including that text since I think it's true for at least some values of support. OK, good. After a bit of wordsmithing and rearrangement I now have this: == clarification text for all versions except GR == This decision is limited to selecting a default initsystem for jessie. We expect that Debian will continue to support multiple init systems for the foreseeable future; we continue to welcome contributions of support for all init systems. The additions, compared to the previous version, are * add for jessie to the first sentence * add the new expect continue to support wording as discussed above (and make it the start of a new sentence as that seems to read better). As I say in the heading comment, this text would appear in both the T (tight coupling) and L (loose coupling) versions. Adrian, does that address your point ? I think that phrasing makes it clear that the remaining text (whether T or L) applies past jessie, too. Ian. -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/21231.45570.802471.640...@chiark.greenend.org.uk
Bug#727708: package to change init systems
Adrian Bunk writes (Re: Bug#727708: package to change init systems): On Mon, Feb 03, 2014 at 07:45:19AM -0700, Bdale Garbee wrote: I've been trying to avoid making decisions now about what happens beyond jessie, but I would not object to including that text since I think it's true for at least some values of support. This discussion started since the Software outside of an init system's implementation may not require a specific init system to be pid 1, although degraded operation is tolerable. in the L rider was interpreted by Russ as being valid forever, while I read the whole resolution text (including this part) as only being valid for jessie. Does a TC vote for this strict rule in the L rider make it binding only for jessie, or forever? This is the important question here. My view is that the T/L rider should apply to jessie+1 and beyond, as well as to jessie. The text I have just emailed would IMO do that. It would be IMO better to make a decision now and explicitly revisit it if it turns out to be wrong, than to make no decision on T/L for jessie+1 and definitely have to have the argument again then. Note that if a GR would re-affirm the TC decision, then a new GR might be needed to change a T/L rider decision if it is not limted to jessie. A GR can selectively uphold the TCs decision if it wants to. Ian. -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/21231.45812.994814.771...@chiark.greenend.org.uk
Bug#727708: package to change init systems
Ian Jackson writes (Bug#727708: package to change init systems): Adrian, does that address your point ? I think that phrasing makes it clear that the remaining text (whether T or L) applies past jessie, too. To expand on what Adrian says in his next mails, the result is that you might have something like this (arbitrarily, I have picked VL to illustrate): The default init system for Linux architectures in jessie should be sysvinit (no change). This decision is limited to selecting a default initsystem for jessie. We expect that Debian will continue to support multiple init systems for the foreseeable future; we continue to welcome contributions of support for all init systems. Software outside of an init system's implementation may not require a specific init system to be pid 1, although degraded operation is tolerable. Maintainers are encouraged to accept technically sound patches to enable improved interoperation with various init systems. This decision is automatically vacated by any contrary General Resolution which passes by a simple majority. In that case the General Resolution takes effect and the whole of this TC resolution is to be taken as withdrawn by the TC, just as if the TC had explicitly withdrawn it by a subsequent TC resolution. I think this wording is unambiguous. The first paragraph applies only to jessie, but the rest of the resolution applies afterwards as well. Bdale, if this is not acceptable to you then please say. Personally I think it is essential for the TC to give now an answer on T-vs-L for jessie+1 and beyond. If the situation changes radically and relevantly between now and then, the TC can of course revisit and modify its own decision. Thanks, Ian. -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/21231.46250.754694.226...@chiark.greenend.org.uk
Bug#727708: package to change init systems
Ian Jackson writes (Re: Bug#727708: package to change init systems): Bdale, if this is not acceptable to you then please say. Bdale has said on irc that he's happy. So I hereby withdraw my previous amendments and propose and accept and do not accept amendments so as to produce the following set of options. I will postpone my CFV until 16:00 UTC on Wednesday. Last call for comments/amendments. Thanks, Ian. Options on the ballot: DT systemd default in jessie, requiring specific init is allowed DL systemd default in jessie, requiring specific init NOT allowed UT upstart default in jessie, requiring specific init is allowed UL upstart default in jessie, requiring specific init NOT allowed OT openrc default in jessie, requiring specific init is allowed OL openrc default in jessie, requiring specific init NOT allowed VT sysvinit default in jessie, requiring specific init is allowed VL sysvinit default in jessie, requiring specific init NOT allowed GR project should decide via GR FD further discussion == version D (systemD) == The default init system for Linux architectures in jessie should be systemd. == version U (Upstart) == The default init system for Linux architectures in jessie should be upstart. == version O (Openrc) == The default init system for Linux architectures in jessie should be openrc. == version V (sysVinit) == The default init system for Linux architectures in jessie should be sysvinit (no change). == version GR (General Resolution) == The Technical Committee requests that the project decide the default init system for jessie by means of General Resolution. == clarification text for all versions except GR == This decision is limited to selecting a default initsystem for jessie. We expect that Debian will continue to support multiple init systems for the foreseeable future; we continue to welcome contributions of support for all init systems. == dependencies rider version T (Tight coupling) == Software may require a specific init system to be pid 1. However, where feasible, software should interoperate with all init systems; maintainers are encouraged to accept technically sound patches to enable interoperation, even if it results in degraded operation while running under the init system the patch enables interoperation with. == dependencies rider version L (Loose coupling) == Software outside of an init system's implementation may not require a specific init system to be pid 1, although degraded operation is tolerable. Maintainers are encouraged to accept technically sound patches to enable improved interoperation with various init systems. == rider for all versions except GR == This decision is automatically vacated by any contrary General Resolution which passes by a simple majority. In that case the General Resolution takes effect and the whole of this TC resolution is to be taken as withdrawn by the TC, just as if the TC had explicitly withdrawn it by a subsequent TC resolution. -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/21231.48047.11025.462...@chiark.greenend.org.uk
Bug#727708: package to change init systems
On Mon, Feb 03, 2014 at 03:13:06PM +, Ian Jackson wrote: Bdale Garbee writes (Bug#727708: package to change init systems): I've been trying to avoid making decisions now about what happens beyond jessie, but I would not object to including that text since I think it's true for at least some values of support. OK, good. After a bit of wordsmithing and rearrangement I now have this: == clarification text for all versions except GR == This decision is limited to selecting a default initsystem for jessie. We expect that Debian will continue to support multiple init systems for the foreseeable future; we continue to welcome contributions of support for all init systems. The additions, compared to the previous version, are * add for jessie to the first sentence * add the new expect continue to support wording as discussed above (and make it the start of a new sentence as that seems to read better). As I say in the heading comment, this text would appear in both the T (tight coupling) and L (loose coupling) versions. Adrian, does that address your point ? I think that phrasing makes it clear that the remaining text (whether T or L) applies past jessie, too. Unfortunately it makes it even worse, this is just adding some (non-binding) expectations to a paragraph that now starts with This decision is limited to selecting a default initsystem for jessie I would still read the paragraphs starting with Software as implicitely being covered by the (now twice) in/for jessie that is there previously. Please add some kind of either For jessie and later releases, or For jessie, to the Software paragraphs to make it clear. Ian. cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140203155748.gc26...@bunk.dyndns.info
Bug#727708: package to change init systems
Adrian Bunk writes (Bug#727708: package to change init systems): On Mon, Feb 03, 2014 at 03:13:06PM +, Ian Jackson wrote: == clarification text for all versions except GR == This decision is limited to selecting a default initsystem for jessie. We expect that Debian will continue to support multiple init systems for the foreseeable future; we continue to welcome contributions of support for all init systems. ... Please add some kind of either For jessie and later releases, or For jessie, to the Software paragraphs to make it clear. I would be happy to do this. Anyone object to me prefixing Therefore, for jessie and later releases: before the T/L Software ... paragraphs ? Ian. -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/21231.49042.634967.524...@chiark.greenend.org.uk
Bug#727708: package to change init systems
Ian Jackson writes (Bug#727708: package to change init systems): I would be happy to do this. Anyone object to me prefixing Therefore, for jessie and later releases: before the T/L Software ... paragraphs ? Following another exchange on IRC I have now done this in git, and I hereby propose and accept that amendment (to all versions). The result is as below. I now intend to do the CFV at 16:30 UTC on Wednesday. Thanks, Ian. Options on the ballot: DT systemd default in jessie, requiring specific init is allowed DL systemd default in jessie, requiring specific init NOT allowed UT upstart default in jessie, requiring specific init is allowed UL upstart default in jessie, requiring specific init NOT allowed OT openrc default in jessie, requiring specific init is allowed OL openrc default in jessie, requiring specific init NOT allowed VT sysvinit default in jessie, requiring specific init is allowed VL sysvinit default in jessie, requiring specific init NOT allowed GR project should decide via GR FD further discussion == version D (systemD) == The default init system for Linux architectures in jessie should be systemd. == version U (Upstart) == The default init system for Linux architectures in jessie should be upstart. == version O (Openrc) == The default init system for Linux architectures in jessie should be openrc. == version V (sysVinit) == The default init system for Linux architectures in jessie should be sysvinit (no change). == version GR (General Resolution) == The Technical Committee requests that the project decide the default init system for jessie by means of General Resolution. == clarification text for all versions except GR == This decision is limited to selecting a default initsystem for jessie. We expect that Debian will continue to support multiple init systems for the foreseeable future; we continue to welcome contributions of support for all init systems. Therefore, for jessie and later releases: == dependencies rider version T (Tight coupling) == Software may require a specific init system to be pid 1. However, where feasible, software should interoperate with all init systems; maintainers are encouraged to accept technically sound patches to enable interoperation, even if it results in degraded operation while running under the init system the patch enables interoperation with. == dependencies rider version L (Loose coupling) == Software outside of an init system's implementation may not require a specific init system to be pid 1, although degraded operation is tolerable. Maintainers are encouraged to accept technically sound patches to enable improved interoperation with various init systems. == rider for all versions except GR == This decision is automatically vacated by any contrary General Resolution which passes by a simple majority. In that case the General Resolution takes effect and the whole of this TC resolution is to be taken as withdrawn by the TC, just as if the TC had explicitly withdrawn it by a subsequent TC resolution. -- -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/21231.49590.318679.462...@chiark.greenend.org.uk
Bug#727708: package to change init systems
On Mon, Feb 3, 2014 at 4:54 PM, Ian Jackson ijack...@chiark.greenend.org.uk wrote: UT upstart default in jessie, requiring specific init is allowed So just to ensure I don't misunderstand: The way I read the texts, you could have e.g. Upstart as default init system and GNOME depend on systemd with UT? Meaning: software could depend on another init system than the default? Just wanting to make sure I am reading this correctly. I was sort of assuming that there would be a preference to rely on the default one. E.g. if you go for Upstart, then preferred to ensure that works. FWIW, I did read all the emails and likely this was explained, but kind of difficult to follow discussions on a phone. Regards, Olav -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cad2dd_ufm6gbhvzjzlq2c0bwjg_ym8nlqxjv82wrn37nd9x...@mail.gmail.com
Bug#727708: package to change init systems
Olav Vitters writes (Re: Bug#727708: package to change init systems): On Mon, Feb 3, 2014 at 4:54 PM, Ian Jackson ijack...@chiark.greenend.org.uk wrote: UT upstart default in jessie, requiring specific init is allowed So just to ensure I don't misunderstand: The way I read the texts, you could have e.g. Upstart as default init system and GNOME depend on systemd with UT? Meaning: software could depend on another init system than the default? Yes, that's what UT says. Just wanting to make sure I am reading this correctly. I was sort of assuming that there would be a preference to rely on the default one. E.g. if you go for Upstart, then preferred to ensure that works. No, none of the options currently proposed make that distinction. Ian. -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/21231.50220.838739.980...@chiark.greenend.org.uk
Bug#727708: package to change init systems
On Sat, Feb 01, 2014 at 10:44:27PM -0800, Russ Allbery wrote: ... I think L is a bad technical design, regardless of the relative merits of the possible init systems that we might switch to. It's effectively equivalent to requiring sysvinit support for all packages indefinitely, and if we thought that was a reasonable design, we would be having a much different discussion. No, it does not require sysvinit support for all packages indefinitely. The current TC decision is *for jessie*. Since the current proposal sets the default only for jessie, it basically implies that a new TC decision and/or GR about init systems will have to be discussed and voted on for jessie+1. AFAIR so far noone has suggested dropping sysvinit support in jessie if jessie supports multiple init systems, but for jessie+1 that can be discussed when the init system discussion for jessie+1 will take place. cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140202100051.gf28...@bunk.dyndns.info
Bug#727708: package to change init systems
Adrian Bunk b...@stusta.de writes: No, it does not require sysvinit support for all packages indefinitely. The current TC decision is *for jessie*. The D/U/O/V/GR options are for jessie. T and L aren't. Nothing in T or L are limited to jessie. If that's what you think they should say, then you need to convince someone to change the current wording, but that's not what we're talking about voting on right now. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87sis147uw@windlord.stanford.edu
Bug#727708: package to change init systems
On Sun, Feb 02, 2014 at 11:44:55AM -0800, Russ Allbery wrote: Adrian Bunk b...@stusta.de writes: No, it does not require sysvinit support for all packages indefinitely. The current TC decision is *for jessie*. The D/U/O/V/GR options are for jessie. T and L aren't. Nothing in T or L are limited to jessie. If that's what you think they should say, then you need to convince someone to change the current wording, but that's not what we're talking about voting on right now. My reading of the current wording in [1] is that in -- snip -- The default init system for Linux architectures in jessie should be ... . This decision is limited to selecting a default initsystem; we continue to welcome contributions of support for all init systems. Software outside of an init system's implementation may not require a specific init system to be pid 1, although degraded operation is tolerable. Maintainers are encouraged to accept technically sound patches to enable improved interoperation with various init systems. This decision is automatically vacated by any contrary General Resolution which passes by a simple majority. In that case the General Resolution takes effect and the whole of this TC resolution is to be taken as withdrawn by the TC, just as if the TC had explicitly withdrawn it by a subsequent TC resolution. -- snip -- there is an in jessie at the top, and it is stated nowhere that any part of this resolution would be outside of the scope of the in jessie. The M option Ian previously suggested [2] had an explicit for the foreseeable future that made the intention clear. If all TC members agree that the T/L riders are not intended to be limited to jessie, can you make that clear by adding a statement like For jessie and later releases, to the front of the middle sections (the ones starting with Software) in the T/L riders? Thanks Adrian [1] https://lists.debian.org/debian-ctte/2014/01/msg00603.html [2] https://lists.debian.org/debian-ctte/2014/01/msg00486.html -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140202210542.gs28...@bunk.dyndns.info
Bug#727708: package to change init systems
On Sun, Feb 2, 2014 at 1:44 AM, Russ Allbery wrote: Cameron Norman writes: This is not really what I was interested in. I want a package for each init system (init-systemd, init-upstart, etc.) that uses something like init-select (under the hood) to prompt the user to change the init system. This will allow packages to depend on a certain init being pid 1, which is essential seeing as the current TC members seem to be leaning towards allowing tight coupling. That can be done now with init-select. For example, any package that requires systemd can currently set /etc/default/init to /bin/systemd, and tell the user that a reboot is required. It will, however, need to manually to check that the user hasn't changed the init setting to something else every time it starts up. That may be as simple as checking that /proc/1/cmdline is /bin/systemd. More generally, this is going to be required as soon as we have a package in the archive that provides a daemon and doesn't have a sysvinit script, pretty much no matter how we get there. Even if we decide on only having a single init system, we still have upgrades from older systems running sysvinit to think of. We *might* be able to dodge out of it if we somehow force the init system switch during a stable release cycle, but even there, it would be a mess in testing during the transition, and I don't think it's a good idea to dodge out of it. If there is no change in default, then we can let users switch inits as they see fit. We can also watch popcon to see which really become popular. Users willing to make a non-default init decision are presumably more capable of dealing with any complications themselves. Sooner or later, we have to have some way to express the fact that a particular package only has startup configuration for a specific list of init systems as a package dependency, unless we think either that (a) we're going to continue to require all packages with daemons to provide sysvinit scripts forever, or (b) it's acceptable to install a daemon package and have it not provide a mechanism to start the daemon. sysvinit support will not be required for packages that have specific init dependencies, since the presence of systemd as init can be checked by those tools that require it. Plus sysvinit support isn't forever, since eventually it will be deprecated as more and more parts of the system drop support for it. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANTw=MNnznh8CDFFDrYr7qWpo9gPcD8RxB40m=xxotrylzn...@mail.gmail.com
Bug#727708: package to change init systems
Adrian Bunk writes (Bug#727708: package to change init systems): This decision is limited to selecting a default initsystem; we continue to welcome contributions of support for all init systems. ... there is an in jessie at the top, and it is stated nowhere that any part of this resolution would be outside of the scope of the in jessie. This is a good point. I think we should fix it. This is IMO a reason not to call the vote tomorrow evening (unless we get a consensus fix before then). The M option Ian previously suggested [2] had an explicit for the foreseeable future that made the intention clear. Yes. I would still prefer to see something like that. I don't remember exactly what the objections were and I'm very very tired now but perhaps something like We expect that Debian will continue to support mkultiple init systems for the foreseeable future. would be acceptable to everyone ? I can't remember what the objections were to my previous wording. Or some other phrasing. If all TC members agree that the T/L riders are not intended to be limited to jessie, can you make that clear by adding a statement like For jessie and later releases, to the front of the middle sections (the ones starting with Software) in the T/L riders? I would be happy to clarify them like that. I prefer the multiple ... foreseeable future approach if we can get consensus on a particular form of words. Thanks, Ian. -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/21230.55642.458640.419...@chiark.greenend.org.uk
Bug#727708: package to change init systems [was: Bug#727708: Processed: block 726763 with 727708]
On Saturday, February 01, 2014 19:14:21 Cameron Norman wrote: On Sat, Feb 1, 2014 at 6:35 PM, Russ Allbery r...@debian.org wrote: I *like* systemd, and I would still be very unhappy if a routine aptitude upgrade (or even a dist-upgrade) of a system currently running sysvinit suddenly resulted in running systemd without some sort of critical debconf question or the like. In my mind, the package to change init systems would still be separate from its respective init systems. There's a work-in-progress tool starting to implement this, it currently works for switching between sysvinit and systemd, and will work with others later (assuming the package interdependencies can be worked out). $ apt-cache show init-select Package: init-select Version: 1.20140109 Installed-Size: 50 Maintainer: Michael Gilbert mgilb...@debian.org Architecture: all Depends: debconf (= 0.5) | debconf-2.0, grub-coreboot | grub-efi-amd64 | grub-efi-i386 | grub-emu | grub-ieee1275 | grub-pc Suggests: systemd Description-en: init system selection tool init-select makes it easy to select among the available init systems (the first process initiated when the system starts). To select an init other than the default, please run the command 'dpkg-reconfigure init-select' after this package has been installed. Note that this will change the init used for all of the available Linux kernel selections in the bootloader menu. . init-select currently only supports the grub bootloader, but this will be expanded to lilo and other bootloaders in the future. This is working for me so far. Doesn't yet work for upstart or openrc, but supporting them is in the TODO list. -- Chris -- Chris Knadle chris.kna...@coredump.us -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2315075.hTDapZqGsy@trelane
Bug#727708: package to change init systems
Cameron Norman camerontnor...@gmail.com writes: This is not really what I was interested in. I want a package for each init system (init-systemd, init-upstart, etc.) that uses something like init-select (under the hood) to prompt the user to change the init system. This will allow packages to depend on a certain init being pid 1, which is essential seeing as the current TC members seem to be leaning towards allowing tight coupling. More generally, this is going to be required as soon as we have a package in the archive that provides a daemon and doesn't have a sysvinit script, pretty much no matter how we get there. Even if we decide on only having a single init system, we still have upgrades from older systems running sysvinit to think of. We *might* be able to dodge out of it if we somehow force the init system switch during a stable release cycle, but even there, it would be a mess in testing during the transition, and I don't think it's a good idea to dodge out of it. Sooner or later, we have to have some way to express the fact that a particular package only has startup configuration for a specific list of init systems as a package dependency, unless we think either that (a) we're going to continue to require all packages with daemons to provide sysvinit scripts forever, or (b) it's acceptable to install a daemon package and have it not provide a mechanism to start the daemon. (b) is probably okay in a few cases, but it's something that Debian has generally tried to avoid, and I support our current approach that the user who installs a daemon is asking for that daemon to actually be installed, configured, and running, not just present on the system waiting for some additional configuration (unless that's somehow unavoidable). I don't think our model of support an init system should be when you use this init system, daemon packages will just randomly not work without any warning until you notice and write configurations for them. If the package doesn't provide configuration for a particular init system, that should be clear from the dependency structure; if the local administrator wants to install the package anyway and provide their own configuration, we have well-established mechanisms to allow for that (such as equivs). I think L is a bad technical design, regardless of the relative merits of the possible init systems that we might switch to. It's effectively equivalent to requiring sysvinit support for all packages indefinitely, and if we thought that was a reasonable design, we would be having a much different discussion. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/871tzmvws4@windlord.stanford.edu
