[Rpm-maint] First attempt for the patch on extending the plugin interface for rpm
elena.reshetova at intel.com
Wed Oct 17 08:17:51 UTC 2012
>> @Tero, do you still remember the reason why the conflict hook was
>> done in this way? Why wasn't it better to check the conflicts before
>> the transaction and fail the whole transaction if conflicts are seen?
> I'm not quite sure about the context you are talking about here, but
> I'll tell what I remember. File conflict hook is called early inside
> rpmtsPrepare when the security plugin doesn't yet know much about the
> package. File conflict hook just records the conflict and the decision
> to go ahead takes place in the FSM hook. Overwriting the conflicting
> file is allowed if package comes from a higher more trusted domain. If
it's not allowed, then FSM hook returns an error and package processing is
>The problem is that while failure in FSM is always a possibility,
>*planning* to fail there is bad as it breaks the one promise rpm gives
about transactions: transaction will not start when there are known
problems. File conflicts need to be handled early, either by resolving them
or aborting the entire transaction before it really even starts.
>Otherwise various calculations will be off, and by the time a package ends
ups in the FSM, some scripts have already been run causing modifications to
the system that can't be undone, plus it can cause broken dependencies to
>Do you happen to remember what information is missing the conflict
resolution stage? I'd guess that would be something internal to the plugin
as from rpm POV, pretty much everything that is known about the packages is
available in rpmtsPrepare().
Thank you Tero for clarifying! This reminded me the actual reason why
decision can't be made in conflict hook for us. I think I just was too tired
yesterday because I miss the obvious thing. The information we are missing
is the package source (we identify it based on package signature). So,
suppose there is a new package X that is about to be installed. It brings
file A that conflicts with the previously installed file from package Y. At
this moment the verify hook for this package hasn't been called yet, so the
plugin doesn't know who signed package X and can't make a decision if it is
ok to overwrite a file or not. I wonder if we can somehow pass the package
signature to this hook then... I will look into this.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 7220 bytes
Desc: not available
More information about the Rpm-maint