[Rpm-maint] FSM hooks for rpm plugin

[Panu Matilainen]

On 03/06/2013 05:01 PM, Reshetova, Elena wrote:
>> What's missing is that another call to the hook is needed in fsmMkdirs() for
>> the unowned directories, and there we should perhaps pass in the "unowned"
>> aspect somehow. Having a separate argument for that seems like an overkill
>> though... maybe we could pass that piece of info in the action argument
>> instead. One possibility could be adding a new action, eg FA_CREATEUNOWNED
>> that could be used for unowned directories (and files, but there aren't any
>> currently). Or we could define the action as a partial bitfield: leave the
>> existing actions alone but reserve the "upper" byte for special bits, such as
>> "unknown". I had some other use-case for turning it into (partial) bitfield
>> but can't remember what it was right now.
>
> I think bitfield would be better in this case: if one start introduce actions
> FA_CREATEUNOWNED, then why not have FA_CREATELINK and etc. I will add hook
> calling for mkdirs, but I think it is better that you do a change of actions
> in a separate commit.

Sure, and I agree bitfield seems like the better option as it'll allow 
cramming a whole lot more information in there. There's a whole lot of 
redundancy in the current actions (all the skip cases for example) and 
some of the values are totally unused as well.

As the file actions aren't really exported in the API in a way that 
somebody could actually be using them, we might be able to get away with 
just redefining the whole thing as a bitfield and add the old symbols as 
defines or'ed together from the bits. But I'll need to think about it 
some more, in any case such a total conversion is not required in order 
to add a handful of bits right now.

> Continue on bit field idea, it would be great for
> plugins to get the basic info about  the file acted upon from action also: so
> , if we are adding unowned bit, should the basic bits indicating hard or sym
> link be also supplied in action? Like action could point that it is creation
> of symlink or removal of hard link. Is it too bad idea?

Hmm, but we already pass the mode (and planning to pass the whole stat 
struct) around, so you can tell whether its a symlink, directory or 
something else. Hardlinks are the more special case but you can tell 
them apart from others by st_nlinks from the stat struct. Except that 
you dont necessarily know which one is "real" file without extra 
tracking... unless st_nlinks is 1 for real files (including the first 
hardlink) and more for the actual links. I'm not sure if that's the case 
even already, but should be possible to arrange at least.

Let me put it this way: I'm not opposed to adding a special flag for 
hardlinks if it turns out its actually needed, but I'm not really 
convinced we need it.

	- Panu -