Packaging: What to do if build dir's pathname is too long

zwol · n00b Joined: 24 May 2024 Posts: 4

I'm trying to make a local package of the Guix overlay package manager and I've run into a weird problem. This software likes to use very long pathnames for things; in conjunction with the path to the build directory it can hit various upper limits on the total lengths of pathnames. For example, the Linux kernel has a hard upper limit of 256 bytes on the length of a #! line. Guix's test suite therefore refuses to run if the path to the build directory is too long, and it turns out that "/srv/pb/portage/sys-apps/guix-1.4.0/work/guix-1.4.0" is too long for it:

Hu · Administrator Joined: 06 Mar 2007 Posts: 21918

Welcome to the forums.

I suppose it would be unacceptable to ask upstream to stop relying on #! lines and invoke their programs as programs (with the script passed as an argument), which would completely avoid the problem.

Taking your path as an example:

/srv/pb: $PORTAGE_TMPDIR. As you found, you can make this a bit better, but there will be a hard minimum of / even if you set PORTAGE_TMPDIR=/ (which may have other interesting and undesirable results). You could recover a bit of space here, but not much.
portage/: this comes from the package manager. A hack to the source code could likely change it, but I don't know how many places you might need to change to keep all the computed paths consistent.
sys-apps/guix-1.4.0/: $P: renaming the ebuild could help here, but that would be very ugly.
work/: this comes from the package manager. As with portage/ above, you could change it, but you might need to change multiple places.
guix-1.4.0: I think this is because the archive has that as its first level directory. You could package the archive with a different name, or move this up a level after unpacking.

logrusx · Veteran Joined: 22 Feb 2018 Posts: 1751

zwol · n00b Joined: 24 May 2024 Posts: 4

zwol · n00b Joined: 24 May 2024 Posts: 4

Genone · Posted: Wed May 29, 2024 8:27 am Post subject:

If the issue is just the length check in the test routine I'd probably just go remove that via patch. It seems to be wrong anyway, the installed package should not contain any paths involving PORTAGE_TMPDIR.

zwol · n00b Joined: 24 May 2024 Posts: 4

Genone · Posted: Wed May 29, 2024 2:45 pm Post subject:

Ah ok, so that length check is a test for the test

Well, one thing you could try then is to redefine $S (the build directory which defaults to "$WORKDIR/$P") in the ebuild. Don't know if it is possible to relocate that outside of $WORKDIR though. $WORKDIR is readonly, so not much chance there without mangling the ebuild name itself. Also sandbox might complain if you try to write outside $WORKDIR.
But should allow to chop off a few chars of the final guix-1.4.0 part at least.

/srv/pb/portage/sys-apps/guix-1.4.0/work/guix-1.4.0 is just 52 chars, so the majority of the problem is the package itself anyway.