On Monday 29 January 2007 15:20, Albert Hopkins wrote:
> On Mon, 2007-01-29 at 09:38 +0200, Alan McKinnon wrote:
> > The real nature of /tmp isn't adequate for portage, that's why it
> > uses a different one. If memory serves, the FHS defines /tmp as a
> > temporary place to store files, and the continued existence of the
> > file after a process has finished is not guaranteed. In other
> > words, if there are no existing locks on a file, it's up for
> > summary deletion. This could be fatal in a big compile - imagine if
> > some cleaner process nuked a binary compiled 4 hours ago in an
> > openoffice compile....
>
> I'm not sure if your memory is correct, but I've always been told
> "never put anything in /tmp that you want to survive a reboot". But
> still using your def I suppose that process would be 'emerge' which,
> on the default config, deletes the files before it finishes anyway.
I don't trust my memory either so I looked it up. The most recent copy
of FHS I have is 2.2:
"The /tmp directory must be made available for programs that require
temporary files.
"Programs must not assume that any files or directories in /tmp are
preserved between invocations of the program."
It says nothing about reboots, that is a common mis-interpretation of
the standard. It usually works just fine, but it's technically wrong.
To be extreme, a daemon could be running that deletes every file
in /tmp as soon as all locks on it are released. This would of course
break every emerge and such a daemon would be insane, but it *is* per
the standard and thus *not* broken. If $PORTAGE_TMPDIR was /tmp and
this did happen, then it is portage's config that is broken, and
nothing else. Weird, huh?
[snip]
> Not that that's ever been a problem for me but you can always
> temporarily divert it when compiling "HUGE" jobs.
>
> # PORTAGE_TMPDIR=/var/scratch/portage emerge openoffice
>
> IMO it's more than worth the convenience/performance of running it
> in /tmp than not. As I've said I've been doing it for a long while
> and I'd don't remember ever having files "disappear" or running out
> of space on /tmp.
Why not just keep it as /var/tmp? Defined as:
"The /var/tmp directory is made available for programs that require
temporary files or directories that are preserved between system
reboots. Therefore, data stored in /var/tmp is more persistent than
data in /tmp.
"Files and directories located in /var/tmp must not be deleted when the
system is booted. Although data stored in /var/tmp is typically deleted
in a site-specific manner, it is recommended that deletions occur at a
less frequent interval than /tmp."
Strictly per the standard, /var/tmp is the correct place for emerge temp
files and /tmp is incorrect. Not that it matters on your box with your
symlink (which is totally standard-compliant btw)
> But if you want to discuss FHS let's talk about how /usr/portage
> doesn't belong in /usr ;-)
Portage shouldn't even begin to start thinking about belonging
in /usr :-). That's why I have:
nazgul ~ # cat /etc/make.conf | grep PORTDIR
PORTDIR="/var/portage"
PORTDIR_OVERLAY="$PORTDIR_OVERLAY /var/local/portage"
DISTDIR="${PORTDIR}/distfiles"
/usr/portage is probably one of those mistakes from way back when that
has become amazingly difficult to fix. Have you noticed that paludis
keeps the portage tree in /var?
alan
--
[email protected] mailing list
