[conspire] libselinux

[Rick Moen]

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
problem.

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
options.