[Rpm-maint] [PATCH 1/2] Extending rpm plugin interface, part 1

Reshetova, Elena elena.reshetova at intel.com
Fri Oct 26 09:56:54 UTC 2012


Please find the corrected patch in the attachment.
I really spend quite some time fighting indentation :( , but let's hope it
succeeded now (I am not that sure since it so much changing when I open it
with different editors/settings).
I was trying to use only soft tabs: 4 spaces, but in places where I had to
integrated in existing code it behaves unpredictable because of hard tabs
that I think in some places aren't of same size (but maybe this is my
inability to use editors).

Best Regards,

-----Original Message-----
From: rpm-maint-bounces at lists.rpm.org
[mailto:rpm-maint-bounces at lists.rpm.org] On Behalf Of Reshetova, Elena
Sent: Monday, October 22, 2012 3:49 PM
To: Panu Matilainen
Cc: rpm-maint at lists.rpm.org
Subject: Re: [Rpm-maint] [PATCH 1/2] Extending rpm plugin interface, part 1

Hi Panu,

Thank you for  the comments! I will post the next version of patch with
corrections soon. My comments for non-cosmetic issues are below and of
course I will fix cosmetics also!

-----Original Message-----
From: Panu Matilainen [mailto:pmatilai at laiskiainen.org]
Sent: Thursday, October 18, 2012 11:44 AM

>AFAICS, with the exception of the actual macro names used, this is
identical to rpmpluginsAddCollectionPlugin(). While not a real showstopper,
I've grown very weary of mopping up the consequences of copy-paste coding in
rpm codebase over the course of the last five years... Unless you foresee
this >significantly diverging from the collection plugin setup, I'd prefer
having these combined or at least made to use a common internal helper from
the start to avoid creeping copy-pasteism :)

Agree, will redo in the next submission.

>Probable copy-paste error, the description should be "pre", right? :)

Oh, yes, sorry, will fix. 

> diff --git a/lib/rpmte.c b/lib/rpmte.c index 35b8e3e..5972505 100644
> --- a/lib/rpmte.c
> +++ b/lib/rpmte.c
> @@ -941,7 +941,7 @@ int rpmteProcess(rpmte te, pkgGoal goal)
>       int scriptstage = (goal != PKG_INSTALL && goal != PKG_ERASE);
>       int test = (rpmtsFlags(te->ts) & RPMTRANS_FLAG_TEST);
>       int reset_fi = (scriptstage == 0 && test == 0);
> -    int failed = 1;
> +    int failed = 0;

>This isn't right, failure from rpmteOpen() would return success from
>rpmteProcess() with this change.

True, a nasty error, will fix.  
>       /* Dont bother opening for elements without pre/posttrans scripts */
>       if (goal == PKG_PRETRANS || goal == PKG_POSTTRANS) { @@ -955,7
> +955,17 @@ int rpmteProcess(rpmte te, pkgGoal goal)
>       }
>       if (rpmteOpen(te, reset_fi)) {
> -	failed = rpmpsmRun(te->ts, te, goal);
> +
> +    	/* Run pre transaction element hook for all plugins */
> +    	if (goal != PKG_PRETRANS && goal != PKG_POSTTRANS) {
> +    		failed = rpmpluginsCallPsmPre(rpmtsPlugins(te->ts), te);
> +    	}
> +	if (!failed) {
> +		failed = rpmpsmRun(te->ts, te, goal);
> +        	/* Run post transaction element hook for all plugins*/
> +        	if (goal != PKG_PRETRANS && goal != PKG_POSTTRANS)
> +    			failed = rpmpluginsCallPsmPost(rpmtsPlugins(te->ts),
> +		}

>Hmm, this might be simpler to handle inside rpmpsmRun() where the
pre/posttrans/verify cruft is already weeded out to a separate case. If left
here, I'd think the condition should be on "scriptstage" instead of
PKG_PRETRANS/POSTTRANS to avoid calling these hooks on verification.

Yes, I guess I'll better move them to psm.c inside rpmpsmRun(). Will look
cleaner since no additional conditions will be needed. 

>FWIW, the collection hooks kinda need to be here as they should be 
even if rpmteOpen() for the last collection elements failed (the logic is a
bit suspect but that's an unrelated issue), but these new hooks are

Yes, I didn't touch the collection hooks, since it looks like the needs are
different between them and the new hooks. 

>> +static rpmRC rpmteSetupTransactionPlugins(rpmts ts)

>Shouldn't this be rpmtsSetup... not, rpmte? :) Probably just a 
leftover from collection plugins which are on the transaction elements.
Yeah, another copy-paste one, sorry :(

> +{
> +    rpmRC rc = 0;
> +    char *plugins = NULL, *plugin = NULL;
> +    char delims[] = ",";
> +
> +    plugins = rpmExpand("%{?__transaction_plugins}", NULL);
> +    if (!plugins || rstreq(plugins, "")) {
> +        rpmlog(RPMLOG_INFO, _("Failed to expand 
> + %%__transaction_plugins
> +	return -1;
> +    }

>Not having any plugins configured is not an error and should not 
in a "normal" setup. Obviously this has to do with wanting to enforce
security plugins being loaded but we need to find some other way to deal
with it. For now, "%{?__transaction_plugins}" evaluating to empty should
just quietly >return with success. (I do see the return code is ignored in
the caller, but the output from here is ugly and causes most of the
test-suite to fail)

Yes, actually this return code is a leftover from the previous case when I
tried to enforce the loading. It is amazing how much you can miss when
looking to the code after many times. Fresh eye is a bliss here! 

> +
> +    plugin = strtok(plugins, delims);
> +    while(plugin != NULL) {
> +	rpmlog(RPMLOG_DEBUG, _("plugin is %s\n"), plugin);
> +        if (!rpmpluginsPluginAdded(ts->plugins, (const char*)plugin)) {
> +	        rc = rpmpluginsAddTransactionPlugin(ts->plugins, (const
> +        }
> +        plugin = strtok(NULL, delims);
> +    }
> +    free(plugins);
> +    return rc;
> +}

>...but any configured plugins failing should indeed abort the thing, so 
caller should take not of the return code.

>Once these mostly minor nits are fixed I think we're good to go. I'm
actually quite eager to have this in so I can start moving the selinux stuff
into a plugin :)

Will do my best in the next version! :)

Best Regards,
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Extending-rpm-plugin-interface-part-1.patch
Type: application/octet-stream
Size: 16773 bytes
Desc: not available
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20121026/641ca3f9/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 7220 bytes
Desc: not available
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20121026/641ca3f9/attachment-0001.p7s>

More information about the Rpm-maint mailing list