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 -
_______________________________________________
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
