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

[Panu Matilainen]

On 10/17/2012 07:49 AM, Tero Aho wrote:
>
>>> Ok, that'd be good. I was actually wondering why its done the way it is now -
>>> if there is an actual reason (such insufficient information available at that
>>> point), I'd like to understand it.
>>
>> My understanding before was that in the current implementation you are able to
>> skip the installation of conflicting files without failing the whole package,
>> but now when I think of this it doesn't seem like a right thing to do.  I have
>> "inherited" these hooks from Tero (in CC now) and while I have done quite some
>> changes to them (some I actually still need to sync to open repo that you get
>> to see them too), I haven't touched the conflict hook at all.
>>
>> @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 canceled.

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

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

	- Panu -