Re: [gentoo-portage-dev] Re: [PATCH] unprivileged mode: generate PORTAGE_DEPCACHEDIR

[Zac Medico]

On 11/09/2014 08:58 PM, Duncan wrote:
> Zac Medico posted on Sun, 09 Nov 2014 15:24:40 -0800 as excerpted:
>
>> [...] then automatically make PORTAGE_DEPCACHEDIR relative to
>> the current target root (which should always be writable for
>> unprivileged mode).
>
> Why?

The "unprivileged mode" is similar to existing prefix support. The
"unprivileged mode" is basically useless unless your target root is
writable. Therefore, it's a sane assumption. It won't affect you unless
you use the new "unprivileged mode". If you do happen to use it, then
you will probably appreciate this patch.

As far as I can tell, the following discussion is about a bug that is
essentially unrelated to my proposed patch:

> Why does emerge --pretend need a writable target root in the first place,
> or it dies a horrible death (traceback)?
>
> I keep root read-only by default, making it writable when I'm updating.
> When I'm simply doing an emerge --pretend, however, whether simply to
> satisfy my own curiosity or because I'm posting a reply to some other
> user where the output from emerge --pretend would be useful, why does
> emerge die a horrible death and traceback, when all I wanted was
> --pretend output that shouldn't be changing the target root at all and
> thus shouldn't /need/ a writable target root in the first place?
>
> https://bugs.gentoo.org/show_bug.cgi?id=490732
>
> FWIW, $PORTAGE_TMPDIR is writable, as is /run/lock (and thus
> /var/run/lock).  In both tracebacks in the bug, it's a *.portage_lockfile
> that's not writable.  Why are those not in (possibly some subdir of)
> /run/lock in the first place, or in $PORTAGE_TMPDIR, given the temporary
> nature of the files?  At least for --pretend.

That bug should be easy to fix. We just need to handle the readonly case.
-- 
Thanks,
Zac