[Rpm-maint] [PATCH 5/5] Add a generic plugin for use by simple Collections

[Panu Matilainen]

On Tue, 22 Jun 2010, Steve Lawrence wrote:

> On Tue, 2010-06-22 at 12:45 +0300, Panu Matilainen wrote:
>> On Mon, 21 Jun 2010, Steve Lawrence wrote:
>>> On Mon, 2010-06-21 at 15:15 +0300, Panu Matilainen wrote:
>>>>
>>>> Oh, another thing wrt chroots: do you have some specific reason to leave
>>>> the chroot handling for the plugins to handle by themselves, instead of
>>>> just doing it in rpmtsRunCollection()?
>>>>
>>>
>>> Parts of the SELinux plugin need to be run outside of the chroot. We're
>>> still finishing this up, but when the plugin is run, it iterates through
>>> all transaction elements with policy and extracts the necessary policy
>>> information (policy names, data, etc). The reading of this data needs to
>>> be done outside of the chroot. Ideally, we wouldn't need to do this, but
>>> this made the most sense in order to keep as much as the SELinux
>>> specific code contained in the plugin as possible.
>>
>> Ok, I suspected this might be the case. It's a bit scary but .. I doubt
>> we're going to have that many plugins anyway, the average collection
>> hardly needs anything beyond the exec plugin.
>>
>> <braindump>
>>
>> If/when the collection ownership is moved to packages, it might be nice to
>> be able to alternatively use just a plain old script for the simple needs
>> too. Eg something like this in the collection owner spec, similarly to how
>> triggers and other scriptlets are defined:
>>
>> %collection fonts
>> /usr/sbin/fc-cache
>>
>> and for the things that actually need a plugin:
>>
>> %collection selinux-policies -p <plugin:selinux.so>
>>
>> ...or something. Just thinking out loud various future possibilities.
>>
>> </braindump>
>>
>
> That seems reasonable to me, and we could maybe reuse some of the
> existing rpmScript code, which would allow more interpreters than just
> the /bin/sh that our current exec.so plugin uses.

Yup, that was the idea. And at least for the non-plugin collections, rpm 
internals would take care of chroot always, we dont want scriptlets 
messing with chroot or executing outside a chroot, ever :)

 	- Panu -