(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…
signature.asc
Description: Digital signature
