On Thu, Sep 04, 2014 at 01:59:57PM +0200, Michael Biebl wrote: > Am 04.09.2014 13:25, schrieb David Kalnischkies: > > Theory is that on a (dist-)upgrade to a new release (jessie) the new > > alternative becomes an invalid choice so that systemd-sysv is choosen as > > it is/was the plan, while on a stable system which is just trying to > > install packages from testing the alternative is a viable choice given > > that an upgrade of/to (any) init system isn't attempt (point release). > > > > > > I haven't tested this at all (just an educated guess from an apt POV), > > but wanted to ask if you think this might be a viable solution and/or if > > you have another idea. > > Say we add the above alternative, is there a risk that on a "real" > dist-upgrade apt will end up *not* upgrading sysvinit, i.e. keeping it > at the wheezy version, and not installing systemd-sysv? > If that would happen, then I'm against adding this alternative.
No, it can't. (dist-)upgrades are a two step action (well, actually any operation, but lets continue…), first pushing all installed packages to the candidate version and then fixing the resulting breakage (if any) with removal/holds. The new alternative is therefore in the first step always invalid and another alternative has to do the job. The problem resolver could decide later on to hold back sysvinit, which would allow him to hold back init, too, but at that stage it has already marked the alternative for installation and more importantly this would mean where is a problem in the form of a not upgradable sysvinit package, so that would be a problem anyhow for the upgrade… > I rather have a bulletproof dist-upgrade experience then trying to > support users mixing stable with testing, which I think is kinda odd > anyways. I mean that's what backports is for. > If they need newer packages they could poke maintainers to provide > backports for such a package. I said the same… (for him nodejs was in backports, while npm isn't), but theory and practice… not every maintainer will be nice an provide backports given that this could mean a lot of additional work… Another thing is that you might have testing sources even if you never install packages from it, but instead do your own backports (stems from the problem that apt doesn't like deb-src entries without deb entries). In short, where are probably a bunch of edgecases, which we probably don't want to support outright, but at least not break if possible. Best regards David Kalnischkies
signature.asc
Description: Digital signature
