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
On 03/28/2013 01:16 PM, Reshetova, Elena wrote:
On 03/27/2013 02:34 PM, Reshetova, Elena wrote:
After far too much pondering... I went ahead and added the prepare
hook
+ some related bits and pieces. And actually ripped out SELinux
+ support
from rpm core while at it, replaced by a simple
After far too much pondering... I went ahead and added the prepare hook
+ some related bits and pieces. And actually ripped out SELinux support
from rpm core while at it, replaced by a simple SELinux plugin. Wohoo.
Looks cool :) Hope it works ;)
I think I'll leave the commit-hooks to you though
On 03/27/2013 02:34 PM, Reshetova, Elena wrote:
After far too much pondering... I went ahead and added the prepare hook
+ some related bits and pieces. And actually ripped out SELinux support
from rpm core while at it, replaced by a simple SELinux plugin. Wohoo.
Looks cool :) Hope it works
On 03/19/2013 03:49 PM, Reshetova, Elena wrote:
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
On 03/15/2013 12:45 PM, Reshetova, Elena wrote:
On 03/14/2013 03:01 PM, Reshetova, Elena wrote:
Sure, I'm not suggesting delaying everything until I someday get
around to fixing it, just that we could try thinking ahead for that
model to hopefully avoid having to change the plugin interfaces
On 03/14/2013 03:01 PM, Reshetova, Elena wrote:
Sure, I'm not suggesting delaying everything until I someday get
around to fixing it, just that we could try thinking ahead for that
model to hopefully avoid having to change the plugin interfaces
later. I pushed a bunch of fsm changes
On 03/13/2013 01:08 PM, Reshetova, Elena wrote:
Do you want to do the changes? I can also try to do it tomorrow if
they aren't objections.
I probably should merge (at least some of) the study and link count patches
first, as those change the landscape quite a bit. I'll try to do that as
Sure, I'm not suggesting delaying everything until I someday get around to
fixing it, just that we could try thinking ahead for that model to hopefully
avoid having to change the plugin interfaces later. I pushed a bunch of fsm
changes yesterday, the two more interesting ones that we already
On 03/14/2013 03:01 PM, Reshetova, Elena wrote:
Sure, I'm not suggesting delaying everything until I someday get around to
fixing it, just that we could try thinking ahead for that model to hopefully
avoid having to change the plugin interfaces later. I pushed a bunch of fsm
changes yesterday,
On 03/12/2013 03:15 PM, Reshetova, Elena wrote:
Setting the permissions before moving would fix that and also avoid
replacing a previous file at all in case we fail to in one of the
metadata steps. For the stock metadata the actual path makes no
difference, but for security labels you'd want the
Do you want to do the changes? I can also try to do it tomorrow if
they aren't objections.
I probably should merge (at least some of) the study and link count patches
first, as those change the landscape quite a bit. I'll try to do that as soon
as the caffeine kicks in for good.
Sure, I
A file is a hard-link if (S_ISREG(st-st_mode) st-st_nlink 1) is true.
When erasing, we get this info from filesystem so that remains accurate (the
last one would be seen as the real file). On installation the stat struct
of a file is made up by rpm, so we can pass whatever we want in there.
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
On 03/07/2013 03:59 PM, Reshetova, Elena wrote:
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
On 03/07/2013 04:27 PM, Reshetova, Elena wrote:
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
On 03/07/2013 07:55 PM, Panu Matilainen wrote:
On 03/07/2013 04:27 PM, Reshetova, Elena wrote:
If instead of hook 2) we have a post fsm commit hook that with proper
parameter, I think it can be serving the same purpose. The only thing
is that
setting permissions before rpm does it isn't
On 03/07/2013 08:05 PM, Panu Matilainen wrote:
On 03/07/2013 07:55 PM, Panu Matilainen wrote:
On 03/07/2013 04:27 PM, Reshetova, Elena wrote:
If instead of hook 2) we have a post fsm commit hook that with proper
parameter, I think it can be serving the same purpose. The only thing
is that
On 03/06/2013 09:42 AM, Reshetova, Elena wrote:
I have been thinking about it now and I think having a hook for setting file meta
data is a good idea in any case (even if we decide to keep pre/post hooks for some
other purpose). It shows much clearer the purpose of the hook and it can be
Another issue I just realized is that with this patch, the metadata hook call
is not under the setmeta condition so it will get called always, ie in cases
like hardlinks when it specifically should *not* be called :)
I think the fsm-part should be something like this instead:
@@ -1569,6
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
I have been thinking about it now and I think having a hook for setting file
meta data is a good idea in any case (even if we decide to keep pre/post hooks
for some other purpose). It shows much clearer the purpose of the hook and it
can be placed nicely exactly where metadata is set (and
On 03/04/2013 10:56 AM, Reshetova, Elena wrote:
Looking at this, I just realized that rpm is currently doing chmod(),
chown() and all for each hardlink it creates, which just doesn't make
sense because ... by the very definition of a hardlink, it doesn't.
Probably worth fixing regardless of what
Looking at this, I just realized that rpm is currently doing chmod(),
chown() and all for each hardlink it creates, which just doesn't make
sense because ... by the very definition of a hardlink, it doesn't.
Probably worth fixing regardless of what we end up doing with hooks,
eg additional
On 02/27/2013 11:14 AM, Panu Matilainen wrote:
On 02/27/2013 08:18 AM, Reshetova, Elena wrote:
Right, no surprises: there is an issue with hard links :)
Oh, this is smth I should have actually remembered, but forgot :( I
saw the
I forgot the specifics of hardlinks too, no worries :)
On 02/27/2013 08:18 AM, Reshetova, Elena wrote:
Right, no surprises: there is an issue with hard links :)
Oh, this is smth I should have actually remembered, but forgot :( I saw the
I forgot the specifics of hardlinks too, no worries :)
issue a while back on our system setup, but since
Right, no surprises: there is an issue with hard links :)
Oh, this is smth I should have actually remembered, but forgot :( I saw the
issue a while back on our system setup, but since from security labelling
hard links aren't interesting (security context should be set on a file
itself, not a
On 02/20/2013 11:01 AM, Reshetova, Elena wrote:
Hi,
Hi, sorry about the delay... the recent patch-flood on rpm-maint caught me by
surprise :)
Patch flood is always good, total silence is much worse :)
Heh, yup :)
I've cleaned it up somewhat now, for example the early return was just
I'm actually going to be mildly surprised if there aren't any strange cases
we've missed wrt hard links or such :) Anyway, the patch looks as
obviously-correct as it gets within fsm. Applied, thanks for the patch!
Yeah, but I guess we will hopefully find it out soon, when we will be using
the
Hi,
Hi, sorry about the delay... the recent patch-flood on rpm-maint caught me by
surprise :)
Patch flood is always good, total silence is much worse :)
I've cleaned it up somewhat now, for example the early return was just plain
wrong as it would've leaked resources all over the place. But
Hi,
I've started to wonder about the hook names though: open and close
seem out of place especially here (and to lesser degree elsewhere).
Perhaps these hooks should simply follow the pre/post pattern even in the
names, ie FILE_PRE and FILE_POST. I think it'd be more descriptive wrt what
they
On 02/04/2013 02:18 PM, Reshetova, Elena wrote:
Hi,
I've started to wonder about the hook names though: open and close
seem out of place especially here (and to lesser degree elsewhere).
Perhaps these hooks should simply follow the pre/post pattern even in the
names, ie FILE_PRE and
On 01/28/2013 02:47 PM, Reshetova, Elena wrote:
Hi,
I am attaching the next version of the patch with modifications explained
inline below.
The patch looks deceptively simple :) In principle things look ok to me,
the issues I see have mostly to do with the symmetry part:
In fsmMkdirs(), the
Hi,
I am attaching the next version of the patch with modifications explained
inline below.
The patch looks deceptively simple :) In principle things look ok to me,
the issues I see have mostly to do with the symmetry part:
In fsmMkdirs(), the FileOpen() hook is not called, only
On 01/22/2013 04:36 PM, Reshetova, Elena wrote:
Hi,
Hi,
Long time again since I replied :( Unfortunately had to resolve a number of
other issues and wanted to attach smth already to this mail as opposite to
just reply.
No worries.
I have started from FSM hooks as you indicated and I am
Hi,
Long time again since I replied :( Unfortunately had to resolve a number of
other issues and wanted to attach smth already to this mail as opposite to
just reply.
I have started from FSM hooks as you indicated and I am including the
initial version of patch for review based on our
On 01/09/2013 08:19 PM, Reshetova, Elena wrote:
Hmm, do you mean FSM_INIT hook is the pre hook and FSM_COMMIT the post
hook, or that both INIT and COMMIT have their own separate pre- and
post-hooks?
Sorry for being unclear, I just meant that for FSM it is better to have two
hooks before file
Hi Panu,
I finally got back to file hooks and tried to look into this with a fresh
head. I think given our previous discussion, I would propose to have only
two symmetrical hooks inside FSM for plugins. I would also make rpm to
ignore any return code from them now, since there isn't much that
On 01/08/2013 02:26 PM, Reshetova, Elena wrote:
Hi Panu,
Hi!
I finally got back to file hooks and tried to look into this with a fresh
head.
Fresh head often helps. I'm afraid my head is a bit too fresh now, as in
details blissfully forgotten :) I'll need to go back and re-read our
39 matches
Mail list logo
