On Mon, 2003-07-07 at 01:09, Martin Pool wrote: > On 23 Jun 2003, Wayne Davison <[EMAIL PROTECTED]> wrote: > > However, if people want to support long-running monitoring of a chain of > > ebuilds would require putting the state dir somewhere outside the home > > directory. Perhaps we could allow the default location to be overridden > > with a DISTCC_STATEDIR environment variable. Or, go back to putting it > > in the temp dir, and implement the DISTCC_TMPDIR suggestion in a way > > that overrides the TMPDIR setting instead of supplanting it. > > I have thought a bit about this: > > I don't think there is anything here that justifies ebuild-specific > hacks. Many users may want to retain visibility of software built by > different users. The most obvious example is tools being built by > root on BSD. Another is compilations taking place inside chroot > environments. > > So I think distcc should note its state in a machine-global location. > That location defaults to (say) /var/lib/distcc, but can be overridden > by setting DISTCC_STATEDIR.
So far I think that any state directory that is not relying on TMPDIR, HOME, or TMP is an optimal solution (and that's why I fixed the state dir in the distcc ebuild patches to /tmp/). Placing the state dir in the /var hierarchy (/var/run/distcc/ perhaps?) seems a logical place to let the files live -- baring any user-restricting permission problems with /var/run. So long as distcc doesn't rely on the three variables I mentioned above (solely to determine where to keep state files) for state files there shouldn't need to be any "ebuild-specific" hacks. That is, hacks to get the monitor programs to work (such as the one I posted in June). -- Regards, -Lisa <Vix ulla tam iniqua pax, quin bello vel aequissimo sit potior>
signature.asc
Description: This is a digitally signed message part
__ distcc mailing list http://distcc.samba.org/ To unsubscribe or change options: http://lists.samba.org/cgi-bin/mailman/listinfo/distcc
