[Rpm-maint] [RFC] Change to Packing Uninstallation Ordering

Panu Matilainen pmatilai at laiskiainen.org
Wed May 12 07:27:56 UTC 2010


On Mon, 10 May 2010, Steve Lawrence wrote:

> After digging into the design of our new Collection idea [1] a bit more,
> we've realized there are potential ordering problems with the SELinux
> part of collections, specifically with upgrades and obsoletes. For
> example, assume we already have foo-1.rpm and foo-policy-1.rpm installed
> and we are upgrading both packages to version 2. Currently, RPM would
> order the upgrade transaction like this:
>
> 1. ADD     foo-policy-2
> 2. ADD     foo-2
> 3. REMOVE  foo-1
> 4. REMOVE  foo-policy-1
>
> RPM first performs all adds, then all removals. This means that the
> sepolicy collection plugin wouldn't be triggered until after step 4,
> when the last member of the sepolicy collection is handled. This means
> that when foo-2 is added, the policy from foo-policy-2.rpm won't be
> loaded yet, resulting in a potential for files with incorrect SELinux
> labels.
>
> Ideally, the ordering would be done like this instead:
>
> 1. ADD     foo-policy-2
> 2. REMOVE  foo-policy-1
> 3. ADD     foo-2
> 4. REMOVE  foo-1
>
> The idea is that all removals are performed immediately after the new
> package is added rather than at the end of the transaction. In this
> case, policy would be loaded after step 2, and foo-2 would be installed
> with the correct SELinux labels.
>
> It seems to us that this change in ordering shouldn't break anything.
> Though, it looks like this ordering was done very deliberately, so maybe
> there are some corner cases or something we are missing.
>
> Thoughts?

A long long time ago, rpm used to do the erasures immediately after the 
upgrade element. Assuming packages have their dependencies right, either 
ordering should be ok for the transaction itself. Where it does make a 
difference is updates on a live system: if erasure of the old version is 
done immediately after new version, there can be large windows where the 
depending packages are broken (consider eg library soname bump) while 
other depending packages are being updated. Doing erasures only after 
everything has been installed helps keeping the system functional while a 
transaction is running, changing that is not really an option I'm afraid.

 	- Panu -




More information about the Rpm-maint mailing list