[Rpm-maint] First attempt for the patch on extending the plugin interface for rpm

Panu Matilainen pmatilai at laiskiainen.org
Thu Oct 11 10:30:41 UTC 2012

On 10/10/2012 05:21 PM, Panu Matilainen wrote:

>>> I think this was one of the prime reasons I had that look into the
>>> "security manager" object thingie: to avoid having to pass the
>>> transaction
>>> set to places where it really does not belong to.
>>> OTOH it would seem to me (most of) the places could simply be passed a
>>> handle to the plugins instead of ts, as the ts is pretty much only
>>> used for
>>> ts->plugins.
>> True, I think this is that I will do: it still requires adding the
>> plugins
>> as parameter to functions, but avoids adding  ts_internal and ts
>> itself. I
>> will change my patch.

Oh BTW, you can avoid most of the new arguments to the fsm internal 
functions by simply storing the plugins handle in the fsm struct itself 
(just like sehandle currently is)

> I understand these concerns (I think :), and tightening rpm security I
> certainly have nothing against. I'm just perhaps looking at this from
> slightly different perspective:
> Many of these issues actually exist on general purpose systems as well:
> for example you wouldn't generally want a 3rd party package from
> somewhere to be able to replace (whether through updating or obsoleting)
> a "system" package or its files. Or have that 3rd party package prevent
> an important update that happens to conflict with a file that the 3rd
> party package has already "claimed". So the kind of package priorization
> by its source / signature and related policies is a much more generic
> need than specialized handheld/embedded systems, the allowability (and
> need) of overriding is what differs more (BTW, how does the user of an
> embedded IVI or handheld device specify an rpm conflict override to
> begin with?)
> That's why I'm a bit doubtful over some things I see here: plugins
> should not (have to) be by design doing strange things behind rpms back
> to achieve what are actually common needs.

Also BTW, to avoid getting stuck from me piling up new demands (I do 
realize that's what's happening here)... I see no reason why this whole 
thing would absolutely have to be merged all at once or not at all, we 
could start merging the easier parts first and worry about the more 
complex issues later, eg:

1) the tsm/psm pre/post hooks are pretty much no-brainers
2) the fsm hooks are mostly obvious but need just a bit of further 
thought/work as already discussed and agreed
3) figure out what to do with the remaining two hooks where at least 
parts of the functionality should IMO be in rpm core

	- Panu -

More information about the Rpm-maint mailing list