Re: [Rpm-maint] FSM hooks for rpm plugin

2013-03-27 Thread Reshetova, Elena

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 :)

Ok, I think I will be able to send you a version for review today, but I have 
got one question. I was under impression that we at some point agreed to pass 
to hooks the whole stat structure as opposite for just mode_t. This would 
allow plugins to make checks on things like st_nlink and other useful info 
about the file. Do I remember this wrongly?

Best Regards,
Elena.


smime.p7s
Description: S/MIME cryptographic signature
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


Re: [Rpm-maint] FSM hooks for rpm plugin

2013-03-27 Thread Panu Matilainen

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 ;)


The basics seem to be working fine :)

The plugin configuration mechanism probably wants a bit more thinking + 
work though: for some things you'd want to be able to enable a plugin by 
merely installing the relevant (sub)package. For example I would want 
the SELinux plugin to get enabled whenever its present, without having 
to hunt where __transaction_plugins is defined and override it,

which is annoying and error-prone.

In other words, I think there should be a drop-in directory for the 
plugin configuration where the plugin sub-packages can drop their 
default configuration as separate files, including whether they should 
be enabled by default or not. There was something else in this direction 
too ... but I can't remember it right now.



I think I'll leave the commit-hooks to you though :)


Ok, I think I will be able to send you a version for review today, but I have
got one question. I was under impression that we at some point agreed to pass
to hooks the whole stat structure as opposite for just mode_t. This would
allow plugins to make checks on things like st_nlink and other useful info
about the file. Do I remember this wrongly?


No, you are right, but I chickened out :) See

http://rpm.org/gitweb?p=rpm.git;a=commitdiff;h=354c00ba7558e2dd78dd6f5906d3ba3e4c41e74a

http://rpm.org/gitweb?p=rpm.git;a=commitdiff;h=3ae4e4087e48e0bbfbafe5c9948bdcbc5fe1c63e

The trouble starts with the special case of fsmMkdirs(): there's a 
struct stat handy, but the directories only get created if the stat() 
fails, in which case the struct stat contents are undefined. Sure, it'd 
be possible to hack up a struct stat that resembles a directory for that 
case, but that rang a proceed with caution alarm bell in my head. If, 
or rather when, we need to fake up stuff the semantics get fuzzy real 
quick. For example the st_nlink thing: the adjusted count is currently 
actually only available in fsmCommit() so different hooks would see 
different values for the same file. Etc.


I still actually think we'll eventually want to pass the whole stat 
struct (or roughly equivalent amount of data in some other means) to 
plugins, being able to sanely do so requires further hacking of the FSM.


- Panu -
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


Re: [Rpm-maint] Rpm Database musings

2013-03-27 Thread Michael Schroeder
On Thu, Mar 14, 2013 at 03:33:44PM +0200, Panu Matilainen wrote:
 What I've had in mind is lumping all the index stuff (possibly along with 
 actual data for the critical parts) into a single file so there'd be just 
 two files db-related files to worry about. But for now, I'm just happy to 
 have an alternative implementation for the pkgs + index databases to play 
 around with :)

I added 'rpmxdb', a meta database that can manage multiple sub-databases.
I changed the rpmidx code so that can can work both with files and
with rpmxdb.

The rpmxdb needs a bit of testing and improving (it doesn't shrink the
file yet if there's much free space), but it seems to work well and
it also is not slower than the file based code.

Cheers,
  Michael.

-- 
Michael Schroeder   m...@suse.de
SUSE LINUX Products GmbH,  GF Jeff Hawn, HRB 16746 AG Nuernberg
main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint