[Rpm-maint] [PATCH 5/5] Add a generic plugin for use by simple Collections
slawrence at tresys.com
Tue Jun 22 20:35:21 UTC 2010
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.
> 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
> 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.
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.
More information about the Rpm-maint