>>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: http://meego.gitorious.org/meego-platform-security/rpm/blobs/taho_dev-4.9.x/tests/rpmmssf.at This link points to the old MeeGo repository since I didn't find these tests in your repo. tero _______________________________________________ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
