On a system upgraded from FC6 with apt, I still have SysVinit 2.86-14. `yum update` wants to replace it with sysvinit 2.86-17, but `apt-get dist-upgrade` doesn't suggest such move. On `apt-get install sysvinit`, it properly wants to replace SysVinit. This may be a problem with versioned Obsoletes: # apt-cache show sysvinit (...) Provides: SysVinit = 2.86-17, sysvinit = 2.86-17 Obsoletes: SysVinit < 2.86-17 I'll keep my system not upgraded to test whatever there is to test, if only I can help with any testing :)
I have just confirmed: the same happens in rawhide. I had to force installation of FC6's SysVinit and try to dist-upgrade. Even the newer apt can't handle the flag correctly.
My guess: it doesn't want to automatically replace SysVinit because it's marked as "essential" package in /etc/apt/rpmpriorities. Try replacing SysVinit -> sysvinit in there.
You're right, it helps. This should be fixed package-wise and made an update for F7. I'm changing the bug summary. I don't have rawhide machine with me ATM, but I suggest looking at "sysklogd", if it isn't fixed already. Thanks for quick answer and excellent suggestion.
Ok, thanks for confirming my suspicion. The problem with rpmpriorities is that it doesn't work at all for distro version upgrades and such, because the priority information is detached from the actual packages. When you start the update, you have the rpmpriorities of the OLD distribution when you really need the rpmpriorities of the NEW distro. What would kind of work (but is not possible atm) is generating rpmpriorities on the fly from information in comps.xml (eg list packages in "Core" as essential), but this has its own set of issues... In other words, not easily fixable. The entries there need to be corrected, sure, but that doesn't really help fixing the generic issue of rpmpriorities brokenness.
So in order to have dist-upgrades work should we perhaps remove SysVinit/sysvinit from all rpmpriorities?
Kind of, except once you start down that path you'll end up with an empty rpmpriorities file: if init of all things doesn't have that extra protection, why should anything have it? Rpmpriorities has always been a double-edged sword - it does add some extra protection for the system but it also messes up things when packages get renamed. I tend to think that the extra protection might weight a little bit more than the trouble it causes though.
When I upgrade Fn to F(n+1), I update glibc, rpm and apt in one transaction and then the rest. In this case, if F7's apt is configured to contain "sysvinit" instead of "SysVinit" in rpmpriorities, it'll work just fine for me on my next FC6->F7 upgrade. Also, if rawhide apt is changed to include rsyslog instead of sysklogd, F7->F8 will work as well. My way of upgrading systems is used by many people and I guess it's even covered by some FAQ-s. I vote for a change :)
apt-0.5.15lorg3.2-12.fc7 has been pushed to the Fedora 7 testing repository. If problems still persist, please make note of it in this bug report.
apt-0.5.15lorg3.2-12.fc7 has been pushed to the Fedora 7 stable repository. If problems still persist, please make note of it in this bug report.