[gentoo-user] ebuild failure in unpack

[gentoo-user] ebuild failure in unpack

[n952162]

I just successfully updated world.  In order to make room in my root, I
subsequently moved /var/tmp/portage to a mounted usb stick and symlinked
it to /var/tmp.

/var/cache/{binpkgs,distfiles} are already successfully located on that
device, over symlinks.

Now, when I try to emerge pavucontrol, all 10 required packages fail,
with a failure in the unpack phase of ebuild.

My mounted storage is:

  /dev/sdb2 on /lcl/USB_SanDisk_3.2Gen1_0901709d...ad012f/2 type ext4
(rw,nosuid,nodev,relatime)

I also have such error messages:

/usr/bin/install: cannot create directory "/var/tmp/portage": Permission
denied
  * ERROR: app-text/iso-codes-4.17.0::gentoo failed (unpack phase):

Apparently, the unpack phase wants to create /var/tmp/portage, and if it
already exists, it failes?

Re: [gentoo-user] ebuild failure in unpack

[Matt Jolly]

Hi,

On 25/2/25 18:05, n952162 wrote:
> In order to make room in my root, I
> subsequently moved /var/tmp/portage to a mounted usb stick and symlinked
> it to /var/tmp.

Have you tried mounting (or bind mounting) to /var/tmp/portage instead 
of symlinking?

Regards,

Matt

[gentoo-user] Re: ebuild failure in unpack

[n952162]

[-- Attachment #1: Type: text/plain, Size: 1334 bytes --]

On 2025/02/25 09:05, n952162 wrote:


I have a second  question that's a follow up to that.

As explained, I moved /var/tmp/portage to a mounted drive and symlinked
it.  When that failed, I copied that directory back to /var/tmp/portage
and was able to emerge pavucontrol.

But now I observe something I don't understand.  The moved directory
tree has these contents:

drwxrwxr-x 3 portage portage 4096 Feb 25 07:20 app-text
drwxrwxr-x 4 portage portage 4096 Feb 25 07:20 dev-libs
drwxrwxr-x 3 portage portage 4096 Feb 25 05:04 dev-python
drwxrwxr-x 3 portage portage 4096 Feb 24 22:25 mail-client
drwxrwxr-x 3 portage portage 4096 Feb 25 07:20 media-libs
drwxrwxr-x 3 portage portage 4096 Feb 25 05:53 net-misc
drwxrwxr-x 3 portage portage 4096 Feb 25 04:50 www-client

But the copied-back directory tree only has these contents:

drwxrwxr-x 3 portage portage 4096 Feb 25 05:04 dev-python
drwxrwxr-x 3 portage portage 4096 Feb 24 22:25 mail-client
drwxrwxr-x 3 portage portage 4096 Feb 25 05:53 net-misc
drwxrwxr-x 3 portage portage 4096 Feb 25 04:50 www-client

Does portage *remove* some files in /var/tmp/portage but retain others?

This is important to me because I want to use this system as a local
binary server to other gentoo systems and because I want to retain the
build environments.


[-- Attachment #2: Type: text/html, Size: 1904 bytes --]

Re: [gentoo-user] ebuild failure in unpack

[n952162]

That's an option.  It means I'd have to dedicate an entire volume to
that, but it's doable.

But if the unpack phase insists on doing a "mkdir /var/tmp/portage",
would that work with a mounted drive?

In fact, it's hard for me to image that the unpack phase would fail on
that, it's just a first guess.  I just want to understand what's going
on and be sure I'm not making some mistake that'll bite me later.



On 2025/02/25 09:16, Matt Jolly wrote:
> Hi,
>
> On 25/2/25 18:05, n952162 wrote:
>> In order to make room in my root, I
>> subsequently moved /var/tmp/portage to a mounted usb stick and symlinked
>> it to /var/tmp.
>
> Have you tried mounting (or bind mounting) to /var/tmp/portage instead
> of symlinking?
>
> Regards,
>
> Matt
>
>

Re: [gentoo-user] Re: ebuild failure in unpack

[Matt Jolly]

On 25/2/25 18:23, n952162 wrote:
>> I have a second  question that's a follow up to that.
> 
> Does portage *remove* some files in /var/tmp/portage but retain others?

Yes. Successful merges are purged, otherwise you'd quickly run out of
disk space.

> This is important to me because I want to use this system as a local 
> binary server to other gentoo systems and because I want to retain the 
> build environments.
> 

See `man make.conf` - keyword "keepwork"[1]. It's a feature that does 
precisely that. It's really not recommended though. What sort of
workflow are you envisioning that would make this useful?

Things can go wrong using keepwork; the existing ebuild environment is
not sourced when reusing ${WORKDIR} (among other things) which I assume
is the intent here, and that can result in unpredictable behaviour.

Regards,

Matt

1: https://devmanual.gentoo.org/eclass-reference/make.conf/index.html

Re: [gentoo-user] ebuild failure in unpack

[Viorel Munteanu]

[-- Attachment #1.1.1: Type: text/plain, Size: 716 bytes --]

La 25.02.2025 10:05, n952162 a scris:
> I just successfully updated world.  In order to make room in my root, I
> subsequently moved /var/tmp/portage to a mounted usb stick and symlinked
> it to /var/tmp.
>
You don't need to use symlinks, you can simply set PORTAGE_TMPDIR in 
your make.conf.

Whatever you use, symlink or PORTAGE_TMPDIR, should not include the 
"portage" directory.  You need to redefine only the "/var/tmp" part, and 
portage will create a "portage" directory inside it.

For example PORTAGE_TMPDIR="/mnt/tmp".

> /var/cache/{binpkgs,distfiles} are already successfully located on that
> device, over symlinks.

You don't need symlinks, set PKGDIR and DISTDIR.


Viorel



[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 10083 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]

Re: [gentoo-user] ebuild failure in unpack

[n952162]

On 2/25/25 09:35, Matt Jolly wrote:
> Hi,
>
>> That's an option.  It means I'd have to dedicate an entire volume to
>> that, but it's doable.
>
> A bind mount will not require this.
>
> > Bind mount operation
> >   Remount part of the file hierarchy somewhere else. The call is:
> >      mount --bind olddir newdir
> > . . .
> >       After this call the same contents are accessible in two places.
> > -- `man 8 mount`
>

Ah!  Excellent idea!  Thank you!


>> But if the unpack phase insists on doing a "mkdir /var/tmp/portage",
>> would that work with a mounted drive?
>
> It seems to be `/usr/bin install`, fwiw. A full build log would make
> troubleshooting anything more than a stab in the dark.
>
> Let's find out. Maybe it doesn't like the symlink?
>
>> In fact, it's hard for me to image that the unpack phase would fail on
>> that, it's just a first guess.  I just want to understand what's going
>> on and be sure I'm not making some mistake that'll bite me later.
>
> I don't know off the top of my head. If you really want to understand
> what's going on you'll need to read the Portage sources.
>
> Regards,
>
> Matt


I think I'll try the really fitting idea from Viorel: PORTAGE_TMPDIR.

I'm still curious about what the problem with the symlink is, in this
case, but I can't get to it right now.


Thanks, all!