[5404] in Release_7.7_team
New tasks for slimming down Athena, and some notes
daemon@ATHENA.MIT.EDU (Greg Hudson)
Fri Jan 27 01:25:59 2006
Date: Fri, 27 Jan 2006 01:25:03 -0500
Message-Id: <200601270625.k0R6P3qQ011341@egyptian-gods.mit.edu>
From: Greg Hudson <ghudson@MIT.EDU>
To: release-team@MIT.EDU
X-Spam-Score: 1.217
X-Spam-Level: * (1.217)
X-Spam-Flag: NO
Here are a couple of new goals and some design notes on one of them,
and also a bit of GConf-related lore.
1. New goal: Native Kerberos build
Explore/prototype Athena release using native Kerberos build
Pretty straightforward. Inventory the Athena changes to Kerberos,
figure out how we might do without them, make sure the build works
against the native libraries, try it out.
2. New goal: Framework for modified Red Hat RPMs
In order to use the native GNOME build, we will probably need a way of
making changes to the native packages as opposed to what we currently
do (build from gnome.org sources using our own build system into
/usr/athena). The framework would have a couple of parts:
* A development methodology for maintaining patches against the Red
Hat sources. This mostly means a script for running "rpmbuild
-bp" on an SRPM and importing the result into a version control
system.
The version control system could be the Athena CVS tree, or a new
Subversion repository for each package. I can think of arguments
for either.
* A script for taking the patch from the version control system, an
Athena release number, and an original SRPM and combining those
into a modified SRPM and RPM.
3. The mystery of the disappearing gconfd-2
I've been trying to figure out under what circumstances a native
gconfd-2 will live and die after kinds of login sessions. This is of
interest because a stale gconfd-2 will generally screw up a future
login because it doesn't have tokens. We have a few hacks in Athena
to prevent that from happening, but the fewer hacks we need, the
better. My findings:
* gconfd-2 will exit when it has no clients and no databases in use.
However, it takes 20 minutes of no accesses for a database to be
marked "not in use", so it takes a long time to clean itself up
after a logout.
* gnome-session will run "gconftool-2 --shutdown" before exiting,
which will cause the daemon to exit. (This is hardcoded in the
gnome-session source.) The Athena Xsession will do the same.
* For an Athena login, sometimes a GConf client will spawn a new
gconfd-2 after the shutdown by Xsession. Panel seems to be the
most common offender (so this doesn't happen much if you log out
via the panel). gnome-session does not have this problem, for the
most part, since it waits for all the X session clients to
terminate before shutting down gconfd-2.
One idea is to run gconftool-2 --shutdown at login time, to clean up
any surviving gconftool-2 (even if it's from an active login whose
tokens have expired). That's not as clean as using a separate
gconfd-2 for each login session, but it might get us closer to being
able to run with an unmodified GConf.
I need to do a similar analysis for the stock
bonobo-activation-server. More on that later.
