rick at linuxmafia.com
Wed Oct 6 13:42:26 PDT 2004
Quoting Greg Dougherty (gregd at molecularsoftware.com):
> I'm trying to get my Fedora 2 installation entirely up to date. You
> would think this would be a simple task. At least, I did.
> I was wrong.
Disclaimer: I'm a little rusty at RPM debugging.
> up2date has two packages it won't upgrade, fam and fam-devel. (I'm at
> 2.6.10-9, there's an FC2 that's available.) It won't upgrade them
> because they require libselinux 1.17. I have libselinux 1.11.4-1
> installed. up2date doesn't appear to want to upgrade it, so I went
> out and downloaded the libselinux 1.17.13-3 rpm.
A reasonable approach. One alternative angle you could try is to remove
fam and fam-devel -- then try up2date-upgrading, then try reinstalling
those two packages. That approach works on some distributions, some of
the time. Don't ask me why: I think the dependency-resolving code just
gets confused or something, and this works (in some cases) around the
A third approach would be to sit on your hands for a couple of days,
hoping that it's a temporary upstream packaging problem that the
package-maintainers will soon fix -- and then re-trying up2date.
> Now, rpm doesn't want to install libselinux, telling me:
> file <name> from install of libselinux-1.17.13-3 conflicts with file
> from package libselinux-1.11.4-1
> It says this even when I pass in the --replacepkgs flag.
> What is going on here? Do I need to do --force? What do I need to do
> in order to turn that damn red update baloon blue?
Further disclaimer: I'm reasoning by analogy with Debian
testing/unstable, here, so I may be speaking through my hat. In
Debian's closer-to-the-bleeding-edge-than-stable-branch packages, it's
not unknown for there to be exactly that sort of problem when a file
suddenly gets moved from one package to another, causing your upgrading
software to (out of caution) refuse to proceed until you provide a
--force-overwrite flag to the dpkg low-level package insertion/removal
tool (analogous to /usr/bin/rpm). In every case where I've had to do
that, it was strictly a one-time fix, necessitated by a gracelessly
handled one-time transition of the named file between two packages.
That having been said, the error you quote -- where rpm basically
complains about package libselinux "conflicting with" an earlier version
of itself -- is damned pecuilar. I could understand up2date balking at
allowing new package B to overwrite installed file bar, on grounds of
bar being already "owned" by installed package A. But this is more like
"I won't allow package A to overwrite file bar because file bar is owned
by package A." Strange.
Anyhow, well, yes, I guess you might have to resort to the --force
More information about the conspire