[distcc] A patch to introduce recursive mkdir and more

[Martin Pool]

On 10 Sep 2003 Lisa Seelye <lisa at gentoo.org> wrote:

> Since I forgot to cc the list last week, here goes:

Sorry I didn't get to it.

> Attached is a patch to address some problems I have had locally; it
> does two things:
> 
> First: It allows for a "mkdir -p" like dcc_mkdir() to create
> directories recursivly.

OK.

> Second: It goes back to pre 2.10's method of storing state and lock
> files.

This is not really how it worked in 2.9, but anyhow...

> The program will now store the state/lock files in
> $DISTCC_DIR/getuid()/{state,lock}.  The notable change is the addition
> of the getuid.
>
> The rational for this is that it allows for centralized placement of
> $DISTCC_DIR where users are unable to reuse the same DISTCC_DIR.
> 
> Users are unable to reuse the pre-patch lock directory because
> currently distcc does not clean out the lock directory after
> compilation is done, and users are not permitted to place their own
> files in the lock directory when there are two concurrent compilations
> running.
> 
> Admittedly this is only a problem in the event of a centralized
> DISTCC_DIR.  The patch stems from my Gentoo-centric view and need to
> have the monitor programs accessable outside a $HOME or $TMPDIR.  This
> patch allows for a globally set DISTCC_DIR to appease Portage and
> users alike.  Users may still reset DISTCC_DIR to their liking (though
> a cosmetic issue of the getuid() still remains).

I don't understand why you think having a single DISTCC_DIR with
per-user subdirectories is any better than each user having their own
DISTCC_DIR.

What is wrong with portage running with (for example)
DISTCC_DIR=/tmp/portage.distcc and then setting the same variable when
a user wants to monitor portage's distcc use?  Then any user who has
permission to read that directory ought to be able to see the tasks...

If there is some Gentoo problem I am happy to help you find a portable
solution.

-- 
Martin