Hi Am 04.09.2014 13:25, schrieb David Kalnischkies: > Pre-Depends: systemd-sysv | sysvinit-core | upstart | sysvinit (<< > 2.88dsf-44) > > [the versionnumber is a guess from the introduction of -core]
As long as the package in question provides /sbin/init, adding another alternative sounds fine in theory. > > 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. 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. Looks like the cleaner solution to me in any case. Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth?
signature.asc
Description: OpenPGP digital signature
