Bug#727708: Processed: block 726763 with 727708
On Sun, Feb 02, 2014 at 12:57:39PM +0100, Tollef Fog Heen wrote: ]] Colin Watson The de facto interface for making an init system the default is to install it as /sbin/init. While I'm coming at this from a starting point different from Cameron's above - I haven't yet decided whether I think it would be good for packages to be able to depend on specific pid 1 implementations - nevertheless, if we select systemd as the default I would argue that there should be some arrangement in packaging to put it in place as /sbin/init, even if that isn't upstream's advertised method. You mean, like installing the systemd-sysv package? Indeed; but people earlier in this thread have said that this isn't the preferred approach, so I was arguing that this *should* be the preferred approach in Debian if systemd is selected as the default, rather than having helper packages that have to wander around fiddling with the configuration of half a dozen different boot loaders to point them to the right place. If the people whose comments I was reading weren't accurately reflecting the position of the Debian systemd maintainers, then I apologise for misunderstanding. -- Colin Watson [cjwat...@debian.org] -- 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/20140204165321.ga11...@riva.ucam.org
Bug#727708: Processed: block 726763 with 727708
]] Colin Watson On Sun, Feb 02, 2014 at 12:57:39PM +0100, Tollef Fog Heen wrote: ]] Colin Watson The de facto interface for making an init system the default is to install it as /sbin/init. While I'm coming at this from a starting point different from Cameron's above - I haven't yet decided whether I think it would be good for packages to be able to depend on specific pid 1 implementations - nevertheless, if we select systemd as the default I would argue that there should be some arrangement in packaging to put it in place as /sbin/init, even if that isn't upstream's advertised method. You mean, like installing the systemd-sysv package? Indeed; but people earlier in this thread have said that this isn't the preferred approach, so I was arguing that this *should* be the preferred approach in Debian if systemd is selected as the default, rather than having helper packages that have to wander around fiddling with the configuration of half a dozen different boot loaders to point them to the right place. It's the preferred way of testing and using systemd while sysvinit is the default, since apt has pathological behaviours once you start replacing Essential: yes packages. Ifwhen the default changes, we'll change the recommended deployment strategy as well. If the people whose comments I was reading weren't accurately reflecting the position of the Debian systemd maintainers, then I apologise for misunderstanding. No worries, I think we got the misunderstanding (if we can even call it that) cleared up. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- 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/m261ourd6a@rahvafeir.err.no
Bug#727708: Processed: block 726763 with 727708
On Tue, 2014-02-04 at 16:53 +, Colin Watson wrote: On Sun, Feb 02, 2014 at 12:57:39PM +0100, Tollef Fog Heen wrote: You mean, like installing the systemd-sysv package? Indeed; but people earlier in this thread have said that this isn't the preferred approach, so I was arguing that this *should* be the preferred approach in Debian if systemd is selected as the default, rather than having helper packages that have to wander around fiddling with the configuration of half a dozen different boot loaders to point them to the right place. If the people whose comments I was reading weren't accurately reflecting the position of the Debian systemd maintainers, then I apologise for misunderstanding. The main issue is that systemd-sysv conflicts with sysvinit-core, while the systemd package doesn't. If you do the first install of systemd with systemd-sysv, this doesn't only change the default, but forces the removal of the whole sysvinit implementation. This can be compared to a kernel package install that forces the removal of all previously installed kernels before you can boot to the new one. So the systemd-sysv route has the clear technical disadvantage that it does not support parallel installation of sysvinit and systemd. I think the ability to easily switch back to sysvinit for troubleshooting if you encounter issues does have some value. Of course, it would be possible to switch /sbin/init while both are installed. -- 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/1391539390.2272.40.camel@glyph.nonexistent.invalid
Bug#727708: Processed: block 726763 with 727708
On Sat, Feb 01, 2014 at 06:21:13PM -0800, Cameron Norman wrote: I think there is a huge problem with recommending that systemd be installed by the user changing the init line in grub: a package can not depend on an init system being PID 1. Can a package be made that changes the init line to systemd? I think that is preferable, because it folows the upstream convention of installing systemd by changing the init value, while also allowing packages to depend on systemd being PID 1. There are a few reasonable possibilities for that; see my comments in #736678. I don't particularly like the convention of passing init=, for much the same kind of reason as I'm in favour of the injunction in http://www.debian.org/doc/debian-policy/ch-opersys.html#s9.9 that a program must not depend on environment variables to get reasonable defaults; the set of boot parameters is user-visible configuration, and I think that the preferred init on any given system, not to mention Debian's default, should be the default value. I can understand the pragmatic reasons for systemd being hooked in using init= while it's a non-default system trying to gain acceptance and to be easy to experiment with on an ad-hoc basis, but as a GRUB maintainer I would prefer that GRUB not need to be involved in the establishment of a default. Furthermore, not everyone uses GRUB and it's going to be pretty tedious to go round all the boot loaders. The de facto interface for making an init system the default is to install it as /sbin/init. While I'm coming at this from a starting point different from Cameron's above - I haven't yet decided whether I think it would be good for packages to be able to depend on specific pid 1 implementations - nevertheless, if we select systemd as the default I would argue that there should be some arrangement in packaging to put it in place as /sbin/init, even if that isn't upstream's advertised method. -- Colin Watson [cjwat...@debian.org] -- 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/20140202110625.ga17...@riva.ucam.org
Bug#727708: Processed: block 726763 with 727708
]] Colin Watson The de facto interface for making an init system the default is to install it as /sbin/init. While I'm coming at this from a starting point different from Cameron's above - I haven't yet decided whether I think it would be good for packages to be able to depend on specific pid 1 implementations - nevertheless, if we select systemd as the default I would argue that there should be some arrangement in packaging to put it in place as /sbin/init, even if that isn't upstream's advertised method. You mean, like installing the systemd-sysv package? (Those packaging choices are done by us in Debian, not upstream.) -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- 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/87ob2plob0@xoog.err.no
Processed: block 726763 with 727708
Processing commands for cont...@bugs.debian.org: block 726763 with 727708 Bug #726763 [gnome-settings-daemon] gnome-settings-daemon: no suspend on close lid, action not configurable, key missing 726763 was not blocked by any bugs. 726763 was not blocking any bugs. Added blocking bug(s) of 726763: 727708 thanks Stopping processing here. Please contact me if you need assistance. -- 726763: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=726763 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- 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/handler.s.c.139128520615130.transcr...@bugs.debian.org
Re: Processed: block 726763 with 727708
On Sat, Feb 01, 2014 at 08:09:24PM +, Debian Bug Tracking System wrote: Processing commands for cont...@bugs.debian.org: block 726763 with 727708 On whose behalf are you setting such a block? You are not listed as a maintainer of gnome-settings-daemon, and even those members of the TC who have been arguing against codifying a requirement to support multiple init systems in the TC resolution have said they want maintainers to work together to provide reasonable support for init systems other than the default. The above 'block' would be tantamount to an assertion that you have no intention of accepting patches from maintainers of non-default init systems to provide compatibility unless forced to do so by the TC; but as you're not a maintainer of the package, that doesn't seem relevant here. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Processed: block 726763 with 727708
Steve Langasek vor...@debian.org writes: The above 'block' would be tantamount to an assertion that you have no intention of accepting patches from maintainers of non-default init systems to provide compatibility unless forced to do so by the TC; Wouldn't it be more reasonable to assume that the proper solution may depend on the TC decision and the corresponding fallout to package naming and structure, and hence it's reasonable to wait for the decision and subsequent fallout (particularly since that's close) rather than doing work now that may not apply to the final state of the world? You had the same reaction to Tollef's desire to wait for the resolution before finding the right way of handling systemd-shim, and I have the same comment. I think it's reasonable, and human, to want there to be a bit less uncertainty and a bit more clarity before starting to do work around init system dependencies. It doesn't necessarily imply a long-term disagreement with the proposed solution; it can just mean that people are hitting overload right now on all the possible paths and want the probability space to collapse a bit before figuring out what they're doing. -- 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/87wqheo9mc@windlord.stanford.edu
Re: Processed: block 726763 with 727708
On Sat, Feb 01, 2014 at 03:24:47PM -0500, Steve Langasek wrote: On Sat, Feb 01, 2014 at 08:09:24PM +, Debian Bug Tracking System wrote: Processing commands for cont...@bugs.debian.org: block 726763 with 727708 On whose behalf are you setting such a block? You are not listed as a maintainer of gnome-settings-daemon, and even those members of the TC who have been arguing against codifying a requirement to support multiple init systems in the TC resolution have said they want maintainers to work together to provide reasonable support for init systems other than the default. The above 'block' would be tantamount to an assertion that you have no intention of accepting patches from maintainers of non-default init systems to provide compatibility unless forced to do so by the TC; but as you're not a maintainer of the package, that doesn't seem relevant here. I'm going to attempt to ignore the confrontational tone of your mail, on the assumption that you can't possibly be proposing that nobody other than a package maintainer should ever do bug triage for fear of stepping on the maintainer's toes. I've done such triage on numerous bugs in the past, including adjustment of blocks, severity (including RC severities), and so on, always on the assumption that the maintainer will agree with the change; that assumption generally holds true. Bug metadata is trivially changed or reverted, and we already have informal policies regarding such metadata, notably the general presumption that the maintainer can always change it if they disagree, and that they have the final say. Thus, implicit in the block added above is the assumption that the maintainer can trivially change it if they disagree; if they did so, I certainly would not change it back and play BTS tennis. The block added above simply reflects the many comments from GNOME folks (and systemd folks for that matter) saying that they're waiting for the fallout to clear before making any drastic changes. Furthermore, it reflects the reality of the current situation: you explicitly stated in the bug log of 726763 that systemd-shim was not ready to serve as an alternative to GNOME (though with different assumptions about how to resolve that), and you furthermore objected to the suggestion of resolving the situation by adding a recommends on systemd-sysv. Thus, I don't see any obvious action the gnome-settings-daemon maintainer could take at this point to resolve 726763 without drawing ire. I would furthermore object strongly to your claim that the block is an assertion that you [sic] have no intention of accepting patches from maintainers of non-default init systems to provide compatibility unless forced to do so by the TC. Metadata is a dynamic thing reflecting the current reality as it stands, and there are no such patches currently on offer. Patches that the maintainers find acceptable would certainly be cause to remove the block (and add the patch tag). See also Russ's very clear response, which I agree with wholeheartedly; thank you, Russ. - Josh Triplett -- 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/20140201214218.GA13928@leaf
Re: Processed: block 726763 with 727708
On Sat, Feb 01, 2014 at 12:34:19PM -0800, Russ Allbery wrote: Steve Langasek vor...@debian.org writes: The above 'block' would be tantamount to an assertion that you have no intention of accepting patches from maintainers of non-default init systems to provide compatibility unless forced to do so by the TC; Wouldn't it be more reasonable to assume that the proper solution may depend on the TC decision and the corresponding fallout to package naming and structure, and hence it's reasonable to wait for the decision and subsequent fallout (particularly since that's close) rather than doing work now that may not apply to the final state of the world? I don't think it's reasonable to leave testing and unstable users of our default desktop environment without working suspend and resume for more than a month (systemd-shim was accepted into unstable on Dec 28, and this was mentioned on the bug) when a one-line change would fix the problem. And that fix would not cease to be correct if the TC decided that only systemd should be supported for jessie, it would just cease to be important. So blocking on the TC decision (as opposed to either uploading the one-liner change or, say, dashing off a message saying I don't intend to work on this but feel free to NMU) does suggest to me that 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. would be ignored, since otherwise I don't see anything in the options the TC is considering, or in the broader discussion generally, which would impact the maintainers' course of action here. In other words: I think the technically correct thing here is obvious and simple and invariant with respect to any decision the TC is going to make; so the only way it makes sense to me that resolving the bug depends on the TC decision is if the maintainers don't intend to do the correct, obvious, simple thing unless the TC /requires/ them to do so. And if we already have examples of this before we've even changed the default init, then I don't think we should pass any resolution that says we welcome multiple init systems while at the same time leaving the door open for maintainers to reject even such simple changes as this. FWIW, I have a moderate preference for a stronger requirement that maintainers be receptive to such patches, rather than dropping the language saying that we welcome multiple init systems in Debian. But that really is just a moderate preference; the thing that bothers me here is declaring that we welcome init systems while not actually providing the policy structure to make that true in practice. I think that's bad precisely because it encourages developers to squander their energy trying to get patches landed that aren't ever going to go anywhere. We can decide that as a project we want to support multiple init systems, or we can decide that we only want to support one init system (per architecture, modulo upgrades) and let those developers make an informed decision to spend their time on other things in Debian; but let's not lead people on by saying one thing and doing another. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Processed: block 726763 with 727708
Steve Langasek writes (Re: Processed: block 726763 with 727708): In other words: I think the technically correct thing here is obvious and simple and invariant with respect to any decision the TC is going to make; (Disclaimer: I have had some wine and am tired. This may make no sense or be going off half-cocked.) This may well be true. I went and skimread #726763 earlier and the log is full things which appear to be irrelevant and it isn't clear to me that there is a specific conclusion being argued. The situation may well be obvious to those deeply involved and following all of the discussion and aware of all the technical issues. Can I suggest you post the one-line patch in question to the bug report, along with a summary of your point of view ? 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/21229.32749.74719.115...@chiark.greenend.org.uk
Re: Processed: block 726763 with 727708
Steve Langasek vor...@debian.org writes: I don't think it's reasonable to leave testing and unstable users of our default desktop environment without working suspend and resume for more than a month (systemd-shim was accepted into unstable on Dec 28, and this was mentioned on the bug) when a one-line change would fix the problem. With the caveat that of course Josh's opinion on the correct status of this bug is not necessarily that of the GNOME maintainers, personally, I simply disagree with this statement. These are not normal circumstances, and normal expectations about usability of unstable and testing do not apply. We're in the middle of one of the most controversial decisions that the project has ever made. I think it's completely reasonable to want to wait for the dust to settle, even if it means that things are temporarily broken in the process. systemd-shim was controversial when you uploaded it, there still are (so far as I know) unresolved questions about conflicts and replaces and configuration file handling, and the whole discussion has been intensely contentious. All sides are making blanket statements that certain things are obvious or easy, which have then been hotly contested by everyone else. The sane thing for a maintainer who doesn't want to wade into this problem to do is to simply do nothing until some sanity and clear direction emerges. -- 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/877g9ezafj@windlord.stanford.edu
Re: Processed: block 726763 with 727708
On Sat, Feb 01, 2014 at 01:42:23PM -0800, Josh Triplett wrote: The block added above simply reflects the many comments from GNOME folks (and systemd folks for that matter) saying that they're waiting for the fallout to clear before making any drastic changes. Furthermore, it reflects the reality of the current situation: you explicitly stated in the bug log of 726763 that systemd-shim was not ready to serve as an alternative to GNOME (though with different assumptions about how to resolve that), and you furthermore objected to the suggestion of resolving the situation by adding a recommends on systemd-sysv. Thus, I don't see any obvious action the gnome-settings-daemon maintainer could take at this point to resolve 726763 without drawing ire. Ok, it seems that wherever I sent my previous note about how I thought this should be fixed, it didn't actually manage to go to the bug log. Sorry about that. While I think the Depends: systemd should be dropped (via a split of the systemd package), that's not required for fixing the present problem. That can be addressed by having gnome-settings-daemon Depends: systemd, systemd-shim | systemd-sysv. Would the GNOME maintainers be willing to upload such a change? Or would they be ok with me NMUing gnome-settings-daemon for it? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Processed: block 726763 with 727708
]] Steve Langasek While I think the Depends: systemd should be dropped (via a split of the systemd package), While you keep asking for this, I think I've quite clearly said I'm not interested in that. You're of course free to suggest it to the CTTE that the systemd maintainers should be overridden about this. On top of all this, I think keep harping on it while we're all waiting for the CTTE to finish making up its mind is asking the wrong entity to act. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- 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/87sis2l7pw@xoog.err.no
Re: Processed: block 726763 with 727708
On Sat, Feb 01, 2014 at 03:24:54PM -0800, Steve Langasek wrote: On Sat, Feb 01, 2014 at 01:42:23PM -0800, Josh Triplett wrote: The block added above simply reflects the many comments from GNOME folks (and systemd folks for that matter) saying that they're waiting for the fallout to clear before making any drastic changes. Furthermore, it reflects the reality of the current situation: you explicitly stated in the bug log of 726763 that systemd-shim was not ready to serve as an alternative to GNOME (though with different assumptions about how to resolve that), and you furthermore objected to the suggestion of resolving the situation by adding a recommends on systemd-sysv. Thus, I don't see any obvious action the gnome-settings-daemon maintainer could take at this point to resolve 726763 without drawing ire. Ok, it seems that wherever I sent my previous note about how I thought this should be fixed, it didn't actually manage to go to the bug log. Sorry about that. Thanks for that clarification. That would explain why I hadn't seen that mail when I reviewed the full bug log. While I think the Depends: systemd should be dropped (via a split of the systemd package), that's not required for fixing the present problem. That can be addressed by having gnome-settings-daemon Depends: systemd, systemd-shim | systemd-sysv. While that would DTRT for users with systemd-sysv installed, it will not work for a majority of current systemd users in Debian, who use systemd via just the systemd package and having init=/bin/systemd on the kernel command line. For such users, this change would attempt to install systemd-shim, which should not happen on systems running systemd. Do you have a suggestion for how to solve that, given the constraints of: - not having systemd-shim conflict with systemd (since you've stated that you'd like to avoid that), - not causing breakage in the systemd package, and - not requiring systemd users to install systemd-sysv? I can think of a few, but none that would be particularly simple to implement or apply. Adding systemd-shim as an alternative to the current dependency on systemd could partially work, with the caveat that users who have systemd installed but are not currently booted into it would experience breakage. As an aside, what is the list of interfaces systemd-shim provides? I previously had the impression that systemd-shim just provided the systemd DBus interfaces that logind depended on, but did not provide org.freedesktop.login1 directly, counting on a forked logind to provide that on top of systemd-shim. Are you saying systemd-shim provides logind's interface directly, and thus satisfies GNOME's full dependency needs already? I'd also point out that there's no reason, other than the common issue of init=/bin/systemd systems (which applies to both orderings) and the current cloud of uncertainty surrounding init systems in Debian, that that dependency couldn't also be written systemd-sysv | systemd-shim. Bug 727708 blocks one of the two alternatives but not the other, and I see no reason not to consider both alternatives equally. - Josh Triplett -- 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/20140202000255.GA16178@leaf
Bug#727708: Processed: block 726763 with 727708
On Sat, Feb 1, 2014 at 3:48 PM, Uoti Urpala uoti.urp...@pp1.inet.fi wrote: On Sat, 2014-02-01 at 15:24 -0800, Steve Langasek wrote: While I think the Depends: systemd should be dropped (via a split of the systemd package), that's not required for fixing the present problem. That can be addressed by having gnome-settings-daemon Depends: systemd, systemd-shim | systemd-sysv. Would the GNOME maintainers be willing to upload such a change? Or would they be ok with me NMUing gnome-settings-daemon for it? I have the impression that systemd-shim diverts systemd files and you don't want to have it installed if you're actually booting with systemd. If this is accurate (I didn't check), then such a dependency change would not be appropriate - the recommended way to install systemd is still to NOT use systemd-sysv, while the above dependency would either force installation of systemd-sysv or would incorrectly install systemd-shim on systemd-booting systems. I think there is a huge problem with recommending that systemd be installed by the user changing the init line in grub: a package can not depend on an init system being PID 1. Can a package be made that changes the init line to systemd? I think that is preferable, because it folows the upstream convention of installing systemd by changing the init value, while also allowing packages to depend on systemd being PID 1. Nevertheless, there still needs to be a org-freedesktop-login1 virtual package. This will allow the systemd packagers to bump to systemd(-logind) v209 and let someone else maintain a systemd(-logind) v204 package in order to use logind without requiring systemd to be PID 1. I think that, with these two packages (one virtual), the systemd packagers will be happy and GNOME can actually function properly with no intervention. -- Cameron Norman
Bug#727708: Processed: block 726763 with 727708
Cameron Norman camerontnor...@gmail.com writes: I think there is a huge problem with recommending that systemd be installed by the user changing the init line in grub: a package can not depend on an init system being PID 1. Can a package be made that changes the init line to systemd? I think that is preferable, because it folows the upstream convention of installing systemd by changing the init value, while also allowing packages to depend on systemd being PID 1. I'm not sure that it's ever going to be sane for simple installation of a package with no further admin interaction to change your init system. If we're going to support multiple init systems going forward, I think we're going to need to figure out some approach to changing the init system that requires *something* besides a package installation. If packages aren't allowed to depend on the functionality of any specific init system, there are various straightforward approaches to this, of which systemd is one that seems reasonable to me. If we do introduce package dependencies on specific functionality, we need to think about how to do this properly. 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. Maybe we can handle this by having a package that changes the default init system but have it throw a critical debconf prompt and fail to install if installed noninteractively. -- 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/87wqhew8bg@windlord.stanford.edu
Bug#727708: Processed: block 726763 with 727708
Russ Allbery r...@debian.org writes: 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. Indeed. Bdale pgpFNkBQwtkEu.pgp Description: PGP signature
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
