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

[Panu Matilainen]

On 10/17/2012 11:17 AM, Reshetova, Elena wrote:
>>> @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().
>
> 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.

Good, this is just the kind of information and understanding I was 
looking for, and it sounds like a solvable problem - signatures have 
long since been read and verified so its more a matter of remembering 
them in some form that can be accessed from here. Whether by remembering 
the signature itself or the signature -> other id (source or whatever) 
mapping done earlier.

It does also sound like something that could use structural changes to 
rpm itself... and here we are back to the ad-hoc nature of the conflict 
hook arguments (which are the way they are because that's all thats 
available from rpm) :)

I mentioned plans to do some pretty fundamental changes to rpm internals 
that would also affect this: one of those things would a unified package 
"object" that can represent both both already installed packages and the 
to-be-installed packages. So where you currently have an rpmte and a 
header, you'd get two objects of the same type, and those package 
objects could (and would) carry information that's not currently present 
in either rpmte and/or header. The details of how all this will end up 
looking are hazy atm, but just so you know...

	- Panu -