Bug#780028: init: aptitude upgrade from wheezy to jessie does not install systemd-sysv

[David Kalnischkies]

(merging two threads)

On Mon, Mar 09, 2015 at 08:02:54PM +0800, Paul Wise wrote:
> On Mon, 2015-03-09 at 08:47 +0100, Axel Beckert wrote:
> > But apt-get has a commandline switch to behave that way, too:
> > "apt-get --with-new-pkgs upgrade"
> 
> Unfortunately not available in wheezy, I expect if it existed there then
> it would also install sysvinit-core.

It wouldn't. upgrade uses the same logic as dist-upgrade does,
just that every forbidden action on packages is changed to a keep
as well as recursively everything broken by this at the end.

That means that 'apt upgrade' isn't choosing sysvinit over systemd
just because it can't install systemd as it requires removes. It will
hold back init instead specifically because systemd requires a remove.

It also means that if you convince the algorithm that systemd is
unavailable as a choice (e.g. with the pin mentioned in the release
notes) 'apt upgrade' would install init with sysvinit.

Which leads us to…

On Mon, Mar 09, 2015 at 11:12:12AM +0100, Axel Beckert wrote:
> Michael Biebl wrote:
> > Actually, I just had an idea. We could make "init" have a Recommends:
> > systemd-sysv in addition to the Pre-Depends: systemd-sysv |
> > sysvinit-core | upstart
> 
> I like that idea!

… the problem(s) with this idea: 'upgrade' is forbidden to break
recommends, so that what I described last isn't happening anymore
(init is again held back).
'dist-upgrade' will happily break them if it has to through, so this
regression is esoteric at best.

My real problem with it is the message this is sending. Not for init
but for how a default choice is made in or-groups in general:
The recommendation of systemd over sysvinit is already expressed by the
or-group order, which is a pretty important property and used all over
the place, not just by init, but httpd, mta, … as its defined as such by
policy (§7.5) in the context of Provides.

It has no practical effects for apt in this specific case as the
decision is already made (via pin or not), but without one it would
be a setup for trouble as or-group members would fight each other as
breaking recommends is bad (which is why aptitude reacts at all).


So, while I can accept if we do this to 'fix' aptitude (and I see also
a bit of semantic value in it) I have to highlight that this is not
a blueprint for defaults in or-groups – quite the opposite and something
should be done to 'fix' this in aptitude in general (even through
I realize that this is dangerously close to core principles).


Best regards

David Kalnischkies

P.S.: I am also realizing now that I 'happily' omitted -core and -sysv
in the mentions of specific inits by accident. So its now left as an
exercise for the reader to add the right suffix at the right place…
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20150310/e74cd75f/attachment-0002.sig>