updates-testing: multilib broken for days now

[Miloslav Trmač]

> On 09/07/15 12:39, Miloslav Trmač wrote:
> >>>          Protected multilib versions: polkit-0.113-1.fc21.x86_64 !=
> >>> polkit-0.112-7.fc21.1.i686
> >>
> >> This is due to polkit splitting out a polkit-libs package between those
> >> two versions. This makes it only include the polkit-libs package
> >> instead of a polkit.i686.
> >>
> >> You should be able to just remove the old polkit.i686, but I agree it
> >> needs to be handed by the package cleanly for upgrades.
> >
> > Oops.  Is there a way to handle this cleanly at all?  I can’t just do
> > polkit-libs.i686 Obsoletes: polkit.i686, that would break 32-bit-only
> > systems.
> 
> How about:
> 
> Obsoletes: polkit < 0.112-7
> (assuming this is the EVR at which the split was introduced)
> 
> https://fedoraproject.org/wiki/PackagingDrafts/MultilibTricks#Splitting_libraries_into_separate_packages
> 
> On a 32-bit system, both polkit and polkit-libs should be updated to
> polkit-0.112-7, whilst on x86_64, polkit-libs-0.112-7.i386 will obsolete
> polkit-0.112-1.i386 and the x86_64 versions will upgrade to 0.112-7 as
> expected.

That doesn’t quite work; yum sees this Obsoletes: and decides to replace polkit with polkit-libs, and then there is no polkit expected to be installed, so the upgraded one will not be installed either.  In most systems this happens to work OK because the polkit package is dragged back in through one of several explicit dependencies on polkit, but a truly minimal install will end up losing the daemon.

I will just revert the split on F21.

(Though the same problem should be happening on F21→F22 upgrades because polkit has been split on F22 from the start.  There were no reports of this problem so far.)
    Mirek