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

Tero Aho Tero.Aho at nixu.com
Wed Oct 17 04:49:28 UTC 2012

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

Btw, there are module tests for different conflict situations here: 
This link points to the old MeeGo repository since I didn't find these tests in your repo.


More information about the Rpm-maint mailing list