Bug#760458: Please add an alternative to 'init' which is satisfiable on stable

David Kalnischkies david at kalnischkies.de
Sat Sep 6 10:27:53 BST 2014


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
-------------- 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/20140906/ac45904c/attachment-0002.sig>


More information about the Pkg-systemd-maintainers mailing list