>> @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. Best Regards, Elena.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
