[Rpm-maint] [PATCH 10/19] Add new policy requires tag to spec file format

Panu Matilainen pmatilai at laiskiainen.org
Fri Mar 5 15:38:21 UTC 2010


On Thu, 4 Mar 2010, Steve Lawrence wrote:

> On Thu, 2010-03-04 at 13:36 +0200, Panu Matilainen wrote:
>> On Tue, 2 Feb 2010, Steve Lawrence wrote:
>>
>>> The PolicyRequires tag is used to specify which versions of packages are
>>> required by policies installed in the module. The PolicyRequires tag has
>>> the same syntax as the Requires tag.
>>>
>>> Assume libselinux-1.2 is installed on the system. Package foo-1.0 has a
>>> policy module that 'Requires: libselinux >= 1.3'. Running the command:
>>>
>>> rpm -Uvh foo-1.0.rpm libselinux-1.3.rpm
>>>
>>> would meet all normal dependencies. However, the policy installation
>>> would still fail because a policy module in foo requires a newer version
>>> of libselinux than is on the system at the time of policy installation
>>> (at the beginning of the transaction). The solution would be to install
>>> the packages in two separate transactions:
>>>
>>> rpm -Uvh libselinux-1.3.rpm
>>> rpm -Uvh foo-1.0.rpm
>>>
>>> However, this is unintuitive and not always possible.
>>>
>>> The new PolicyRequires directive solves this problem. The directive is
>>> simply a list of dependencies, in the same format as the Requires tag,
>>> that specifies what packages must already be installed at the start of
>>> a transaction for policy modules to be successfully installed. This will
>>> most commonly be packages like libselinux or checkpolicy.
>>
>> This is another sub-case of a more generic problem and deserves a generic
>> solution.
>>
>> rpmlib() dependencies are pretty much the same as this: they must be
>> satistied by the rpm running the transaction in question and can't be
>> resolved by adding more/newer packages to the set.
>>
>> What this needs is essentially RPMSENSE_RUNTIME (and make RPMSENSE_RPMLIB
>> a subcase/equivalent of that). The tricky part is again initial install to
>> chroot: you can't look into the target rpmdb for providers as there will
>> be none. Does libselinux export its version through API? If so, it could
>> be used to generate an rpmlib()-style provide at runtime. Looking at hosts
>> rpmdb is not really an option as it might not even exist (installer
>> run-time image for example)
>>
>>  	- Panu -
>>
>
> Could you expand on the RPMSENSE_RUNTIME/rpmlib ideas a bit? We're not
> quite sure how that would work.

I dunno if RPMSENSE_RUNTIME is a good name at all, the point is that 
there's a class of dependencies that cannot be satisfied by anything in 
the transaction but are run-time preconditions. Rpm has one sub-case of 
this implemented in rpmlib() dependencies, which track various rpm 
capabilities. For example if a package is built using XZ payload 
compression, a dependency on "rpmlib(PayloadIsXz)" is automatically added 
to such packages. This is something only the rpm used to run a transaction 
can provide - an update to rpm adding this capability wouldn't help to 
perform the transaction.

Another similar case is the version of the running kernel: unlike 
libraries etc, just upgrading the kernel package in a transaction doesn't 
change the running version.

The libselinux version requirement for policy installation is just like 
these in nature. I just want a generic solution to this problem class - 
which I suppose is my headache to implement, you just take advantage of it 
then.

> Also, none of the selinux libraries export version information.

Ok ... we'll just need to figure something out then. One simple (if 
inflexible) way could be adding a static rpmlib-style provide based on the 
version of libselinux rpm was built against.

 	- Panu -


More information about the Rpm-maint mailing list