Re: Bug#762194: Alternative proposal for init switch on upgrades.

2014-11-30 Thread Cameron Norman
On Sat, Nov 29, 2014 at 11:15 PM, Tollef Fog Heen tfh...@err.no wrote:
 ]] Cameron Norman

 On Sat, Nov 22, 2014 at 6:10 PM, Adam Borowski kilob...@angband.pl 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.

2014-11-30 Thread Tollef Fog Heen
]] Cameron Norman 

 On Sat, Nov 29, 2014 at 11:15 PM, Tollef Fog Heen tfh...@err.no wrote:
  ]] Cameron Norman
 
  On Sat, Nov 22, 2014 at 6:10 PM, Adam Borowski kilob...@angband.pl 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



Bug#762194: Alternative proposal for init switch on upgrades.

2014-11-29 Thread Cameron Norman
On Sat, Nov 22, 2014 at 6:10 PM, Adam Borowski kilob...@angband.pl 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.

2014-11-29 Thread Tollef Fog Heen
]] Cameron Norman 

 On Sat, Nov 22, 2014 at 6:10 PM, Adam Borowski kilob...@angband.pl 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



Bug#762194: Alternative proposal for init switch on upgrades.

2014-11-25 Thread Svante Signell
On Sun, 2014-11-23 at 13:55 -0700, Bdale Garbee wrote:
 Svante Signell svante.sign...@gmail.com 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.

2014-11-25 Thread Ansgar Burchardt
Hi Svante,

Svante Signell svante.sign...@gmail.com 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.

2014-11-23 Thread Svante Signell
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.

2014-11-23 Thread Bdale Garbee
Svante Signell svante.sign...@gmail.com 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.

2014-11-22 Thread Cameron Norman
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.

2014-11-22 Thread Adam Borowski
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