Red Hat Bugzilla – Bug 249323
/etc/apt/rpmpriorities contains "SysVinit" instead of "sysvinit"
Last modified: 2007-11-30 17:12:11 EST
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
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
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.