Bug 249323 - /etc/apt/rpmpriorities contains "SysVinit" instead of "sysvinit"
Summary: /etc/apt/rpmpriorities contains "SysVinit" instead of "sysvinit"
Alias: None
Product: Fedora
Classification: Fedora
Component: apt   
(Show other bugs)
Version: 7
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Axel Thimm
QA Contact: Fedora Extras Quality Assurance
Depends On:
Blocks: 252323 252324
TreeView+ depends on / blocked
Reported: 2007-07-23 18:42 UTC by Leszek Matok
Modified: 2007-11-30 22:12 UTC (History)
1 user (show)

Fixed In Version: 0.5.15lorg3.2-12.fc7
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-08-06 17:56:51 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Leszek Matok 2007-07-23 18:42:02 UTC
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 :)

Comment 1 Leszek Matok 2007-07-23 18:53:02 UTC
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.

Comment 2 Panu Matilainen 2007-07-25 08:34:11 UTC
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.

Comment 3 Leszek Matok 2007-07-25 10:02:41 UTC
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.

Comment 4 Panu Matilainen 2007-07-25 11:18:21 UTC
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

Comment 5 Axel Thimm 2007-07-25 11:34:17 UTC
So in order to have dist-upgrades work should we perhaps remove
SysVinit/sysvinit from all rpmpriorities?

Comment 6 Panu Matilainen 2007-07-25 11:41:41 UTC
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.

Comment 7 Leszek Matok 2007-07-25 12:03:33 UTC
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 :)

Comment 8 Fedora Update System 2007-08-03 02:40:04 UTC
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.

Comment 9 Fedora Update System 2007-08-06 17:56:43 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.