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

[Panu Matilainen]

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>

>> And actually looking at rpmtsRunCollection() and how its called etc...
>> seems to me the whole thing could be buried inside rpmte.c around
>> rpmteProcess() so rpmteLastInCollectionAdd() and friends wouldn't be
>> needed even in internal API.
>>
>
> I think we'll still need rpmteCollection() and rpmteHasCollection() to
> be public for the SELinux plugin, but the other collection helpers can
> be removed/hidden.

This is fine, those two are the ones that look like potentially useful 
outside deep rpm internals.

>> Errors from collection hooks is something to think about too. Currently
>> rpm only considers elements failed when %pre, %preun or payload processing
>> fails, but does callback notifications for all scriptlet failures (with
>> warning/error indicator). The collections patch set makes collection-hook
>> failures to show up in rpmtsRun() return code as errors while not going
>> through the other mechanisms (marking elements failed, notifying through
>> callback). Which makes the already fuzzy semantics even fuzzier :)
>>
>
> So, should a collection failure mark the te that caused that collection
> action to be run as failed? Even though the failure isn't really part of
> the te? Maybe just the RPMCALLBACK_COLLECTION_ERROR is enough, and let
> the callback handler deal with it?

I think RPMCALLBACK_COLLECTION_ERROR callback notification is sufficient 
and in line behavior of triggers etc: they wont prevent the package from 
being laid on disk so they're only considered warnings and not fail the 
entire element.

 	- Panu -