Bug#762194: Alternative proposal for init switch on upgrades.
Hello everyone, Since I myself and some others had some criticisms and/or doubts of Adam Borowski's proposal, I would like to propose a different one. With this I hope to: * make new installations use systemd-sysv (with no reliance on undefined or inconsistent behavior from the various ways of setting up a Debian install or chroot) * make current installations that have sysvinit stick with it * allow for the automatic switch from sysvinit to systemd-sysv in stretch, buster, or another later release So, the change would be that: the sysvinit package would cease being a transition / shim package, however it would not signal that a user explicitly installed sysvinit; sysvinit-core would be a simple package that just depended on sysvinit, and the presence of this package *would* signal that the user explicitly installed sysvinit; init would (pre-)depend on "systemd-sysv | sysvinit | sysvinit-core | upstart". If an automatic switch is something that the project wants, but after Jessie, then then the init dependency would be changed to "systemd-sysv | sysvinit-core | upstart". Cheers, -- Cameron Norman -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/calzwfrj_qv1vpwrcvtr7hakj1ivw8nn_dmzp8h1q8xkbbzk...@mail.gmail.com
Bug#762194: Alternative proposal for init switch on upgrades.
On Sat, Nov 22, 2014 at 05:29:42PM -0800, Cameron Norman wrote: > I would like to propose a different one. [...] > > So, the change would be that: the sysvinit package would cease being a > transition / shim package, however it would not signal that a user > explicitly installed sysvinit; sysvinit-core would be a simple package > that just depended on sysvinit, and the presence of this package > *would* signal that the user explicitly installed sysvinit; init would > (pre-)depend on "systemd-sysv | sysvinit | sysvinit-core | upstart". I'm afraid this doesn't allow partial upgrades from wheezy to use systemd-sysv, as sysvinit is an essential package there, and apt considers packages to be essential if they're present in any source. -- // If you believe in so-called "intellectual property", please immediately // cease using counterfeit alphabets. Instead, contact the nearest temple // of Amon, whose priests will provide you with scribal services for all // your writing needs, for Reasonable and Non-Discriminatory prices. -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141123021014.gb12...@angband.pl
Bug#762194: Alternative proposal for init switch on upgrades.
On Sun, 2014-11-23 at 03:10 +0100, Adam Borowski wrote: > On Sat, Nov 22, 2014 at 05:29:42PM -0800, Cameron Norman wrote: > > I would like to propose a different one. > [...] > > > > So, the change would be that: the sysvinit package would cease being a > > transition / shim package, however it would not signal that a user > > explicitly installed sysvinit; sysvinit-core would be a simple package > > that just depended on sysvinit, and the presence of this package > > *would* signal that the user explicitly installed sysvinit; init would > > (pre-)depend on "systemd-sysv | sysvinit | sysvinit-core | upstart". > > I'm afraid this doesn't allow partial upgrades from wheezy to use > systemd-sysv, as sysvinit is an essential package there, and apt considers > packages to be essential if they're present in any source. Do people use the usb stick/cd/dvd etc for upgrades to jessie, i.e. the debian installer. Or do they only use apt/aptitude/etc? -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1416742353.11764.280.ca...@g3620.my.own.domain
Bug#762194: Alternative proposal for init switch on upgrades.
Svante Signell writes: > Do people use the usb stick/cd/dvd etc for upgrades to jessie, i.e. the > debian installer. Or do they only use apt/aptitude/etc? I don't know that we can speak in absolutes, but I've never personally seen or heard of anyone using debian-installer to do an upgrade. Bdale signature.asc Description: PGP signature
Bug#762194: Alternative proposal for init switch on upgrades.
On Sun, 2014-11-23 at 13:55 -0700, Bdale Garbee wrote: > Svante Signell writes: > > > Do people use the usb stick/cd/dvd etc for upgrades to jessie, i.e. the > > debian installer. Or do they only use apt/aptitude/etc? > > I don't know that we can speak in absolutes, but I've never personally > seen or heard of anyone using debian-installer to do an upgrade. Has the proposed (pre-)depends ordering on init been tested and the results known? The technical solution asked for in #765803 might be the above for upgrades. The installer is not used for upgrades and is no issue here. -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1416945651.11764.294.ca...@g3620.my.own.domain
Bug#762194: Alternative proposal for init switch on upgrades.
Hi Svante, Svante Signell writes: > Has the proposed (pre-)depends ordering on init been tested and the > results known? You might want to read https://bugs.debian.org/762194#142, but the obligation for tests is really on the side of the people who want this change (IMO). Ansgar -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/8761e3nioo@deep-thought.43-1.org
Bug#762194: Alternative proposal for init switch on upgrades.
On Sat, Nov 22, 2014 at 6:10 PM, Adam Borowski wrote: > On Sat, Nov 22, 2014 at 05:29:42PM -0800, Cameron Norman wrote: >> I would like to propose a different one. > [...] >> >> So, the change would be that: the sysvinit package would cease being a >> transition / shim package, however it would not signal that a user >> explicitly installed sysvinit; sysvinit-core would be a simple package >> that just depended on sysvinit, and the presence of this package >> *would* signal that the user explicitly installed sysvinit; init would >> (pre-)depend on "systemd-sysv | sysvinit | sysvinit-core | upstart". > > I'm afraid this doesn't allow partial upgrades from wheezy to use > systemd-sysv, as sysvinit is an essential package there, and apt considers > packages to be essential if they're present in any source. I take it you mean that the user will have to remove an essential package to install systemd-sysv, not that the package will not be installable, correct? That seems reasonable to me. If the user has packages from Wheezy installed, those packages could reasonably depend on sysvinit as PID 1 without expressing that dependency. It would be a bug, IMO, if sysvinit was not PID 1 while Wheezy packages were installed and the user had not expressed that he or she understood the implications of removing sysvinit. Thus, I maintain that my proposal is an appropiate approach. Cheers, -- Cameron Norman -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/calzwfr+g3rqjwecw08xkjm8hxjihb5e11qzkzvxbwbamvzp...@mail.gmail.com
Bug#762194: Alternative proposal for init switch on upgrades.
]] Cameron Norman > On Sat, Nov 22, 2014 at 6:10 PM, Adam Borowski wrote: > > On Sat, Nov 22, 2014 at 05:29:42PM -0800, Cameron Norman wrote: > >> I would like to propose a different one. > > [...] > >> > >> So, the change would be that: the sysvinit package would cease being a > >> transition / shim package, however it would not signal that a user > >> explicitly installed sysvinit; sysvinit-core would be a simple package > >> that just depended on sysvinit, and the presence of this package > >> *would* signal that the user explicitly installed sysvinit; init would > >> (pre-)depend on "systemd-sysv | sysvinit | sysvinit-core | upstart". > > > > I'm afraid this doesn't allow partial upgrades from wheezy to use > > systemd-sysv, as sysvinit is an essential package there, and apt considers > > packages to be essential if they're present in any source. > > I take it you mean that the user will have to remove an essential > package to install systemd-sysv, not that the package will not be > installable, correct? > > That seems reasonable to me. If the user has packages from Wheezy > installed, those packages could reasonably depend on sysvinit as PID 1 > without expressing that dependency. No. They could reasonably depend on sysvinit being installed. We ship alternative inits in wheezy, some of which does not require sysvinit to be uninstalled (systemd and runit comes to mind, I would not be surprised if there are more). However, in the tradition of Essential packages, nowhere is it well-defined which of sysvinits interfaces were part of the essentialness and which are not. I kinda wish we'd fix that at some point, to make it easier to swap out (or get rid of) Essential packages. -- 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: https://lists.debian.org/m2r3wlrwf2@rahvafeir.err.no
Re: Bug#762194: Alternative proposal for init switch on upgrades.
On Sat, Nov 29, 2014 at 11:15 PM, Tollef Fog Heen wrote: > ]] Cameron Norman > >> On Sat, Nov 22, 2014 at 6:10 PM, Adam Borowski wrote: >> > On Sat, Nov 22, 2014 at 05:29:42PM -0800, Cameron Norman wrote: >> >> I would like to propose a different one. >> > [...] >> >> >> >> So, the change would be that: the sysvinit package would cease being a >> >> transition / shim package, however it would not signal that a user >> >> explicitly installed sysvinit; sysvinit-core would be a simple package >> >> that just depended on sysvinit, and the presence of this package >> >> *would* signal that the user explicitly installed sysvinit; init would >> >> (pre-)depend on "systemd-sysv | sysvinit | sysvinit-core | upstart". >> > >> > I'm afraid this doesn't allow partial upgrades from wheezy to use >> > systemd-sysv, as sysvinit is an essential package there, and apt considers >> > packages to be essential if they're present in any source. >> >> I take it you mean that the user will have to remove an essential >> package to install systemd-sysv, not that the package will not be >> installable, correct? >> >> That seems reasonable to me. If the user has packages from Wheezy >> installed, those packages could reasonably depend on sysvinit as PID 1 >> without expressing that dependency. > > No. They could reasonably depend on sysvinit being installed. We ship > alternative inits in wheezy, some of which does not require sysvinit to > be uninstalled (systemd and runit comes to mind, I would not be > surprised if there are more). > > However, in the tradition of Essential packages, nowhere is it > well-defined which of sysvinits interfaces were part of the > essentialness and which are not. I kinda wish we'd fix that at some > point, to make it easier to swap out (or get rid of) Essential packages. Would systemd-sysv having a `Provides: sysvinit` fix this issue? I think if the pre-installation /etc/inittab checking that has been discussed is implemented then systemd could reasonably be considered to provide sysvinit's interfaces (especially with the /dev/initctl compatibility). Thank you, -- Cameron -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CALZWFRL_8DtvpvM=gunqtnfpwo3lszvku6pvtve3sc3eabg...@mail.gmail.com
Re: Bug#762194: Alternative proposal for init switch on upgrades.
]] Cameron Norman > On Sat, Nov 29, 2014 at 11:15 PM, Tollef Fog Heen wrote: > > ]] Cameron Norman > > > >> On Sat, Nov 22, 2014 at 6:10 PM, Adam Borowski wrote: > >> > On Sat, Nov 22, 2014 at 05:29:42PM -0800, Cameron Norman wrote: > >> >> I would like to propose a different one. > >> > [...] > >> >> > >> >> So, the change would be that: the sysvinit package would cease being a > >> >> transition / shim package, however it would not signal that a user > >> >> explicitly installed sysvinit; sysvinit-core would be a simple package > >> >> that just depended on sysvinit, and the presence of this package > >> >> *would* signal that the user explicitly installed sysvinit; init would > >> >> (pre-)depend on "systemd-sysv | sysvinit | sysvinit-core | upstart". > >> > > >> > I'm afraid this doesn't allow partial upgrades from wheezy to use > >> > systemd-sysv, as sysvinit is an essential package there, and apt > >> > considers > >> > packages to be essential if they're present in any source. > >> > >> I take it you mean that the user will have to remove an essential > >> package to install systemd-sysv, not that the package will not be > >> installable, correct? > >> > >> That seems reasonable to me. If the user has packages from Wheezy > >> installed, those packages could reasonably depend on sysvinit as PID 1 > >> without expressing that dependency. > > > > No. They could reasonably depend on sysvinit being installed. We ship > > alternative inits in wheezy, some of which does not require sysvinit to > > be uninstalled (systemd and runit comes to mind, I would not be > > surprised if there are more). > > > > However, in the tradition of Essential packages, nowhere is it > > well-defined which of sysvinits interfaces were part of the > > essentialness and which are not. I kinda wish we'd fix that at some > > point, to make it easier to swap out (or get rid of) Essential packages. > > Would systemd-sysv having a `Provides: sysvinit` fix this issue? I'm not sure which of my two points you're addressing, but I don't think it would fix either. Packages in wheezy can assume the interfaces provided by sysvinit are present without any kind of dependency. (Arguably, they can only assume those in squeeze are present, if one wants to support partial upgrades, but that's not particularly important here.) Whether systemd-sysv in jessie Provides sysvinit or not has no influence on this; there's no dependency being tracked. Whether it Provides: sysvinit or not does not change the level (or lack thereof) of documentation on which of sysvinit's interfaces are Essential. For instance, I would be surprised if /usr/include/initreq.h is considered part of the Essential interfaces, and by that I mean more the «you don't need to depend on this», rather than the «must work when not configured». The latter is trivial for a .h file, except it includes bits from libc6-dev, which I think we all agree should not be considered transitively Essential, because that would be crazy. /sbin/runlevel and /sbin/telinit I would consider part of the Essential interface of sysvinit, but my point is: nowhere is this documented, so different people will make different assumptions here. > I think if the pre-installation /etc/inittab checking that has been > discussed is implemented then systemd could reasonably be considered > to provide sysvinit's interfaces (especially with the /dev/initctl > compatibility). Some of them, sure. All? No. And I'm still not sure which problem you'd be trying to solve with that. -- 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: https://lists.debian.org/87mw785spx@xoog.err.no
