updates-testing: multilib broken for days now
kalevlember at gmail.com
Thu Jul 9 18:12:48 UTC 2015
On 07/09/2015 07:48 PM, Miloslav Trmač wrote:
>> On 09/07/15 12:39, Miloslav Trmač wrote:
>>>>> Protected multilib versions: polkit-0.113-1.fc21.x86_64 !=
>>>> 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
>> How about:
>> Obsoletes: polkit < 0.112-7
>> (assuming this is the EVR at which the split was introduced)
>> 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
> 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.
The obsoletes should probably go to polkit itself so that the new
polkit.x86_64 package obsoletes both polkit.i686 and polkit.x86_64
-libs shouldn't need any obsoletes or other special handling since other
packages that depend on -libs would just pull in the correct i686 or
x86_64 version as needed.
At least this is how it used to work with yum; might need some testing
to make sure dnf's depsolver handles obsoletes the same way.
Hope this helps,
More information about the devel