[Rpm-maint] FSM hooks for rpm plugin

[Panu Matilainen]

On 03/06/2013 12:34 PM, Reshetova, Elena wrote:

>> I see basically two options: either feeding the file bit by bit to a plugin as we read it, or using a pre-commit hook where the whole thing is unpacked onto disk but before moving to final position. The latter option seems far easier in many ways, both for the >plugin and the rpm-side. OTOH there *could* be uses for hooks that get fed the files chunk-by-chunk, such as to allow custom checksums and the like.
>> Checksums can of course be calculated from the final file in pre-commit too, but then you need to re-read the entire thing.
>
> Yeah, in my second email I also started to lean towards the second
> option. So, it looks like your pre/post commit hooks study might be
> useful even more. You mentioned before that smth about it didn't feel
> right, do you have smth in mind or?

That something was mostly about trying to fit the symmetric hooks 
through asymmetric use-hole, but that's not all: I still have this 
nagging feeling we're missing some "obvious" way of doing this all in a 
simpler way. Or something to that direction... exposure to the fsm tends 
to mess up any clear thinking :)

> If we now see a proper use case: like pre-commit can be used for
> content checking or even checksum calculation (I would still probably
> prefer to calculate it when it is read from archive: feels a bit safer
> that way, while I understand logically that if file is in tmp location
> and properly protected, nothing should happen to it anyway).

Yup, if you get it directly from the "source" then nothing can be 
tampering with it, and certainly for at least checksum calculation is 
going to be more efficient if you can do it on the fly (but then rpm can 
do multiple checksums already, what's missing is exporting that 
functionality in a sane way). OTOH if something can tamper with the file 
that we're creating then it can do nasty stuff anyway, so its perhaps a 
bit academic.

>> Another concrete use-case could be a plugin to put %config files into a version control of some kind. While this too would mostly be interested in actually created/erased files, it might actually want to know about %ghosts and such to be able to snapshot >changes made by admin that might've occurred outside of the package. Guess this needs further thought, or better yet, actually trying to do it, but this might be a use-case for the current hooks as they are now, getting called for all files of a package >whether actually touched or not.
>
> This almost drives us to have this set of hooks:
>
> 1) pre/post where they are now
> 2) metadata hook (both install and remove)
> 3) pre fsm commit hook for checking on a file content ()
>
> Indeed needs more thinking ....

Naah, we just need more hooks! :P

Seriously though, I've started thinking of that very same set of hooks 
so we're probably not too far off-target here. But now I find myself 
wondering whether 2) is actually necessary afterall: if we have pre- 
(and perhaps post too) commit hook, and can pass in some additional 
information as file action flag bits... we could have something like 
FA_SETMETA bit for the entries where its appropriate (ie non-hardlinks I 
guess), and if there's a post-commit hook as well, the plugins can 
decide whether to set permissions before or after rpm.

Yes, needs more thinking :)

	- Panu -