> Should we do the stat passing then for fsmCommit hooks? I am attaching > the current state of my fsmCommit hooks just to show the place where I > was thinking to add them. I haven't checked the tabs and other stuff, > so this is just to give idea. I was thinking that instead of passing > mode_t to the both hooks (in this patch it still does that), the whole > stat stuct can be passed and this would give at least these hooks > enough info. What do you think? Or if is too bad/assymetric to have mode_t > in other hooks and stat here?
>I think we better leave the stat struct out of the picture for now. Its not >just that the information in the stat struct would be more than a bit fuzzy, >but also its not really sufficient either. For example a %config management >plugin would need to know >whether a file is a %config or not, and that's >currently not available to plugins without jumping through a lot of hoops. >What we'd really need is being able to pass rpmfi objects to the hooks (in >addition to some other things), but that requires largish >changes in the rpm >internals... But I've talked about that long enough maybe its time to >actually do it. It shouldn't be a particularly *difficult* change, just >fairly large and tedious one. Ok, I will then stick with mode_t for now and then we can get a proper rpmfi object later. >As for the preliminary patch, yes that's what I was thinking of as well >- in particular, calling the pre-commit hook before fsmBackup() so in case a >backup is needed, the pre-commit hook can grab the contents before its moved >out of the way. There are some open questions here too >however: if there's a failure, the post-commit hook doesn't really know >whether it was the backup that failed or the actual commit. True, but question is does it need to differentiate? If backup has failed, commit can't be successful, isn't it? And then there's the special case of directory replacing something else, in which case the backup is (and needs to be) >taken in rpmPackageFilesInstall() already. And then there's the whole erasure business to deal with... >Just wondering if there actually should be *yet another* hook for backups, >which would allow avoiding the ambiguity in fsmCommit() and make plugins >aware of all the scenarios in which backups are taken. So many hooks, sigh... >dunno. Hm... I am not against new hooks, but they are staring to multiply quite fast... I will try to think more about it... In general I think we should not introduce the hooks unless good use case is present, otherwise we will lose track of them and create interfaces that noone else is using. So, the question is does a backup operation is smth plugin should be aware and understand or it is now fully internal to rpm operation. At least we're >not in danger of running out of "supported hooks" bits anymore :) I changed the plugin initialization >+ hook-calling system fairly radically over the weekend as discussed. Nice :) I will take a look on it after I am back from travelling in 1.5 weeks and then will be also able to continue on the patch! Best Regards, Elena.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
