Bug 760793

Some additional information about the problem:

sssd-1.5.1-66.el6 made some changes that required new SELinux policy (if
SELinux is installed). Because it is possible to install SSSD on a system
without the selinux-policy package installed, we were instructed to use:

Conflicts: selinux-policy < 3.7.19-118

This should ensure that the policy version must be 3.7.19-118 or later in order
to install this version of SSSD. Unlike using Requires:, this will not forcibly
install selinux-policy if it's not currently on the system.

The problem is that the yum depsolver does not treat optional-requires of this
construction the same way that it treats Requires:

There is no guarantee by the depsolver that the policy will be updated before
SSSD is. As a result, while the final state of the yum transaction included the
correct versions of both of these packages, because the updated selinux-policy
was not installed before SSSD, it fails to successfully restart SSSD on
upgrade.

Yup, conflicts aren't considered on ordering. This case does suggest they should be, but I'll need to mull over it a bit to consider whether doing so would have any negative side-effects.

> The problem is that the yum depsolver does not treat optional-requires of this
> construction the same way that it treats Requires:
> 
> There is no guarantee by the depsolver that the policy will be updated before
> SSSD is. As a result, while the final state of the yum transaction included the
> correct versions of both of these packages, because the updated selinux-policy
> was not installed before SSSD, it fails to successfully restart SSSD on
> upgrade.

With the rawhide rpm you can enforce installing the new selinux-policy before the new sssd with 

OrderWithRequires: selinux-policy

This won't create a requirement on selinux-policy yet will ensure selinux-policy is installed before sssd if whenever they are in the same transaction.

What kind of selinux policy change are we talking about here exactly? If it involves new/changed labels, ordering is not enough to do anything about this as rpm uses the context label definitions that existed when the transaction started. So in addition to somehow ordering selinux first, rpm would potentially need to learn to reload the labels in middle of transaction which has its own set of issues.

Anyway, conditional nak - we should be able to do something about this specific case, "generic fix" for the rpm <-> selinux interactions is likely to be beyond the scope of rhel-6 however.

*** Bug 784289 has been marked as a duplicate of this bug. ***

(In reply to comment #5)
> What kind of selinux policy change are we talking about here exactly? If it
> involves new/changed labels, ordering is not enough to do anything about this
> as rpm uses the context label definitions that existed when the transaction
> started. So in addition to somehow ordering selinux first, rpm would
> potentially need to learn to reload the labels in middle of transaction which
> has its own set of issues.

In our particular case, it is only the addition of new rules on existing labels. So the ordering would be sufficient.

It does sound like OrderWithRequires: is the right answer here, but as discussed above it isn't available yet on RHEL 6. So what is the right course of action here? Breaking upgrades on SSSD is a very serious issue.

I'm still looking to hear how we can handle this in SSSD for 6.3.

Since RHEL 6.3 External Beta has begun, and this bug remains
unresolved, it has been rejected as it is not proposed as
exception or blocker.

Red Hat invites you to ask your support representative to
propose this request, if appropriate and relevant, in the
next release of Red Hat Enterprise Linux.

*** Bug 820759 has been marked as a duplicate of this bug. ***

This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.

*** Bug 905104 has been marked as a duplicate of this bug. ***

Devel-ack for backporting the OrderWithRequires feature. The differences in the code base are not so severe as it first looked like.

OTOH NACK for considering conflicts for ordering. This is a way to intrusive change with unforeseeable consequences.

This request was evaluated by Red Hat Product Management for
inclusion in a Red Hat Enterprise Linux release.  Product
Management has requested further review of this request by
Red Hat Engineering, for potential inclusion in a Red Hat
Enterprise Linux release for currently deployed products.
This request is not yet committed for inclusion in a release.

This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.

Devel-ack for backporting the OrderWithRequires feature.

Pasting here the feature description, just for the record.

OrderWithRequires

Packages can supply extra transaction ordering hints via new OrderWithRequires tag. This follows Requires tag syntax, but does not generate actual dependencies. Only if the involved packages are present in the same transaction, the ordering hints are treated as if they were Requires when calculating the transaction order.

Fixed in rpm-4.8.0-46.el6.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2015-1452.html