[Rpm-maint] First attempt for the patch on extending the plugin interface for rpm
pmatilai at laiskiainen.org
Wed Oct 17 09:12:14 UTC 2012
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
>> 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 -
More information about the Rpm-maint