Michael Meskes <mich...@fam-meskes.de> writes: >> PackageKit uses the very same resolver as apt itself does... A log >> file of what actually happened would be very helpful here, to determine >> the problem causing the package removal.
> Just try an update on a recently updated (Sunday) sid system and you'll > see see the conflicts. I'm unclear as to what you have installed that triggers this, because I've been using systemd and sid for eons and have never encountered this behavior. (That also makes me pretty sure, pace Steve, that this is not something *systemd* as systemd is actually doing, but some other component.) Is it GNOME Software that you also have installed, per the other message on this thread? Looking at systemd-system-update-generator, it looks like this is a purely optional feature that is only triggered if you use a system upgrade method that uses the /var/lib/system-update staging area. So I think blaming this on systemd is a little odd. I certainly agree that it's a rather serious bug for this to suddenly start happening without your knowledge, particularly when it makes some decidedly bad dist-upgrade choices, but I think the fault here lies with whatever software staged this upgrade. Not with systemd for just doing what it was told by another package. I like having the *choice* of being able to either use apt and upgrade directly, or stage an upgrade and have it happen on reboot. It seems like systemd is providing that choice and supporting both options, which is great. The question, in my mind, is why you're getting surprised with something using the method that you don't prefer. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
