[Toybox] toybox debian patch for PATH_MAX.

[Rob Landley]

On 9/14/22 06:10, Antoni Villalonga wrote:
> Path 'set-pathmax-default.patch' was a quick dirty fix trying to build Toybox
> for Debian/Hurd.
> 
> Hurd build log before the patch:
>   https://buildd.debian.org/status/fetch.php?pkg=toybox&arch=hurd-i386&ver=0.8.8%2Bdfsg-1&stamp=1660914245&raw=0
>   ( scripts/kconfig/lex.zconf.c:2263:22: error: ‘PATH_MAX’ undeclared (first use in this function) )

Hopefully I addressed that one.

> Hurd buildlog after the patch:
>   https://buildd.debian.org/status/fetch.php?pkg=toybox&arch=hurd-i386&ver=0.8.8%2Bdfsg-2&stamp=1663073011&raw=0
>   ( ./lib/portability.h:183:10: fatal error: sys/mount.h: No such file or directory )
>   Still needs more work :-/

lib/portability.h and lib/portability.c are the place to stick all the horrible
#ifdefs for target whack-a-mole, so if you want to stick an #ifndef __HURD__ or
similar around that #include it's the right place for it. :)

>   I'll try to look at it but probably there are too much work to be done.

No rush, you saw how long it took me to catch up to your initial pokes about
this. :)

> Some coments PATH_MAX:
>   https://www.gnu.org/software/hurd/hurd/porting/guidelines.html
>   https://pubs.opengroup.org/onlinepubs/009695399/basedefs/limits.h.html
>    | {PATH_MAX}
>    |  Maximum number of bytes in a pathname, including the terminating null character.
>    |  Minimum Acceptable Value: {_POSIX_PATH_MAX}
>    |  [XSI] Minimum Acceptable Value: {_XOPEN_PATH_MAX}
> 
> At this point I'll probably drop my PATH_MAX patch from Debian package.

The kconfig build should work without it, and as far as I know nothing in toybox
proper uses it.

I didn't avoid it because I thought headers might not have it, but because the
value in the headers is meaningless. Linux removed its page size limitation a
while ago, and you could always violate it with:

  while true; do mkdir -p a b; mv a b; mv b a; done

And then rm -rf had better be able to _cope_. (And posix makes a note about
implementing rm -r with chdir instead of path-from-root. I used openat()
instead, and still need to fix up the rest of dirtree to work right here...)

> May be toybox upstream can rely on _POSIX_PATH_MAX/_XOPEN_PATH_MAX mentioned on
> opengroup docs in case PATH_MAX is not defined.

Those are even more meaningless: they don't describe anything about the current
environment you're running in. You can ask for the _POSIX_ and _SC_ ones with
getconf.

> I didn't mentioned it as an 'issue' on github because it's only a Hurd-related
> problem.
> 
> Thanks for your time!
> 
> PS: I've seen your other email. I need to look deeper on it before replying.

I went through the rest of the patches in your git repo, and I think I've
applied everything relevant that doesn't require more info?

We went over pathmax-default, and I applied a kconfig fix.

For silent-blhc I suggested trying HOSTCC="$HOSTCC --flags" in the build
invocation instead (because cross and host compilers can need different $CFLAGS,
which is _why_ I didn't add it to both).

timeout.patch is already a backport.

I don't now why you're removing use of binary files from the test suite?

I applied the spelling changes (I can't reliably spell separate, I know).

I applied the path changes too, although there's been a couple variants of that
from other people over the years: Khem Raj had one for OpenEmbedded... commit
b8070a742549 in 2019, and commit 1dd3704c5ffe was about matching this up with
busybox in 2015. If you start playing tug-of-war please work it out among
yourselves. Android doesn't care (it does an install_flat into something like
/system/bin), and I've been symlinking /bin to /usr/bin and /sbin to /usr/sbin
since forever (something other people have apparently copied from me since an
old busybox rant about it went semi-viral circa
https://www.linux.com/news/ever-changing-linux-filesystems-merging-directoris-usr/).
tl;dr: when I tried to research WHY some things are in /bin and some in /usr/bin
ages ago I actually managed to prove a negative (there IS no good answer, and I
know WHY, although my writeup got the disk sizes wrong: the fast system disk was
0.5 megs, each RK05 is 2.5 megs. It's more or less "boot from a comparatively
tiny ssd and plug in two giant external USB disks", except 50 years ago.), and
having a binary live in /bin vs /sbin is a "primiarly used by root or by regular
users" aesthetic judgement call where it's blurry because "normal users can
mount stuff that fstab lets them" and "normal users type ifconfig to see what
this machine's IP address is all the time" really doesn't leave you with a very
good answer. (Systems that don't have /sbin in the path for normal users rank up
there with trying to make dash your login shell. The command will TELL me if I
don't have permissions to do what I tried to do, don't make me type in the path
to run it.)

That's all six patches you had checked in. (I also applied the s390 fix you sent
this morning.)

Rob