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

[Steve Lawrence]

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.

> >> 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.
> 

Makes sense.