[Rpm-maint] FSM hooks for rpm plugin

[Reshetova, Elena]

>
> Hm... I guess you are right: even without changing fsm, such hook can be introduced now and started to be used right away. But do you want to have one hook (for install and erase) or two hooks (pre- and post-process)? I think having pre- hook isn’t very beneficial, but post-unpack is the needed one. >Maybe we can call it smth like FilePrepare or so to indicate that file is tmp location and hook is called to setup the necessary attributes and check the file?

>Hmm, I kinda like that: FilePrepare is generic enough that it can be used for both installs (ie post create) and erasures (pre remove). Dunno if its *the* most descriptive name possible but really good names are annoyingly hard to come by with :) It's good enough for now in any case. 
>And yeah, having separate pre/post hooks is probably an overkill for this purpose.

>BTW I further hacked fsm yesterday to move the metadata setting out of
>fsmCommit() into the main rpmPackageFilesInstall() loop. It doesn't make much of a difference technically yet, but I think it makes it a bit easier to think about it as a separate step from commit when it actually is :)
Yes, I think this is a good idea: committing the file and setting its metadata are indeed two different steps. 

>
>> The only thing that I can't find so far a usage for pre commit hook 
>> for future: it would be kind of called on the same context (file is 
>> unpacked in tpm dir) and the future metadata/content screening 
>> hook.... One idea can be that for security needs, plugins can 
>> actually use pre- and post hooks to verify that permissions were 
>> preserved (and
>> set) correctly and abort if they see some mismatch. But maybe this is 
>> too paranoid again :)
>
>> That's perhaps slightly paranoid, yes :) But then its not my job to say what the plugins should be used... for some purpose having yet another layer of verifying might be reasonable.
>
>> One use-case I see for the pre- and post-commit hooks is a plugin keeping track of config file contents: in pre-commit it would stage the change of content (think of "git apply"), and in post-commit it would either commit or abort (think of "git commit" or >"git reset --hard") depending on whether fsm commit succeeded or not.
>
> Yes, I think this might be a better use case than a paranoid plugin :) So, then we have 3 hooks: pre- and post- commit and some kind of filePrepare after unpack. I think this should be smth we will be able to leave with for quite a while even when fsm is changed.

>Yup, those three hooks are something I think we can reasonably expect to stay semantically the same no matter how much things change underneath. 
>That's perhaps been one of the bigger problems in introducing the file
>hooks: trying to wedge hooks with sane semantics onto the twisted beast that fsm was (and of course still is, if to slightly lesser degree) ... 
>well, fsm fights back with vengeance every step of the way :)

OK, so how should we proceed on this? Will you commit the hooks or should I try to do a patch and send it for review?

Best Regards,
Elena.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 7220 bytes
Desc: not available
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20130319/7435e108/attachment.p7s>