[rfc] move activation to a helper process

[John (J5) Palmieri]

On Thu, 2006-10-19 at 19:55 -0400, David Zeuthen wrote:
> On Thu, 2006-10-19 at 18:48 -0400, Havoc Pennington wrote:
> > What I meant by "system directory" is "one of the service file 
> > directories listed in system.conf" - in fact, maybe we don't need to 
> > check owned by root if you think that will cause problems - if you make 
> > the service file directory writable by users, I guess it's probably your 
> > own fault... maybe it's even useful in some scenarios to let certain 
> > groups write to one of these directories.
> 
> Yeah. I think so too. Driving home tonight I remembered how jhbuild
> works; IIRC some (most?) people install to /opt/gnome2 where /opt/gnome2
> normally is owned by non-root, e.g. the user that builds it. 
> 
> So, the crux of the problem is that any included .conf file can include
> <servicedir> plus the user might change system.conf. So essentially we
> need to watch for a) the system.conf configuration file changing; and b)
> all the directories in <includedir>. Which brings us back to parsing the
> entire configuration at least. We could cache this and watch for
> configuration file changes. Does that sound reasonable? 
> 
> (It's just more code running as uid 0 plus need for test cases... That's
> kinda why I wanted to punt it.)
> 
> > 
> > > We could also just commit all the code for 1.0, I mean it's a nice
> > > feature and if it doesn't work we should fix it soon :-)
> > 
> > I was deferring to John on this point - though I was thinking he was 
> > trying to make FC6, and it looks like we didn't make FC6, so there may 
> > be no hurry now other than embarrassment that reaching 1.0 is taking for 
> > frickin' ever.
> > 
> > It'd be nice to stick 1.0 in an FC6 update though, so maybe we should 
> > really try to stick to a freeze.
> 
> Yeah, well, uh, I dunno. I'd like the feature to get in 1.0 mostly so
> because I think people would expect it to be there. I'm also not sure
> rushing things for something as fundamental as D-Bus is a good idea
> either. Then again, the buck needs to stop somewhere. But, sure, putting
> the patch in D-Bus 1.1.0 [1] or whatever is feasible too, it just feels
> weird to put a major feature in an update release. Plus that release
> might not come out for some time as other feature development is
> ongoing.


So I an not sure what feature you are talking about or if it is the
whole patch but I'm going to have to say no for the reason that we want
to get 1.0 out and be stable.  Large code drops just mean another month
of waiting to see if things break.  0.94 is pretty stable and I am
mostly waiting on FreeBSD patches that I may not wait on all that long.

1.1.0 will be the development branch with 1.2.0 becoming the stable
version after 1.0 is released.  If your patch stabilizes in there others
can back-port it and if it doesn't change 1.0 interfaces eventually have
it in an official 1.0.x release if people are asking for it.

The purpose of 1.0 is build confidence from ISV's (and by ISV's I mean
anyone using D-Bus who does not hack on core) that D-Bus is a stable
interface to build their software on top of.  It also gives the windows
guys and other platforms a stable target to port.  I for one want to
stop worrying about it and start profiling and optimizing some of the
internal parts and start to stabilize the python bindings.

-- 
John (J5) Palmieri <johnp at redhat.com>