GNU bug report logs - #20713
aclocal/tar.m4 and solaris 5.10 where `id -u` is not supported

Previous Next

Full log

Message #18 received at 20713 <at> debbugs.gnu.org (full text, mbox):

From: Mike Frysinger <vapier <at> gentoo.org>
To: Karl Berry <karl <at> freefriends.org>
Cc: 20713 <at> debbugs.gnu.org
Subject: Re: aclocal/tar.m4 and solaris 5.10
Date: Mon, 21 Feb 2022 19:57:30 -0500

[Message part 1 (text/plain, inline)]

On 21 Feb 2022 16:26, Karl Berry wrote:
>     should we change "unknown" to $GID & $UID respectively ?
> 
> I guess it couldn't hurt, although I doubt it makes any difference in
> practice.

i feel like you just accidentally wrote Automake's motto :p

>     if test $am_uid = "unknown"; then
> 
> Don't we usually avoid quoting constant strings? I.e.:
> if test "$am_uid" = unknown; then

tbh, i have no idea what the quoting style/preference is in the GNU world,
if there actually is one.  i know i see plenty of underquoting, and plenty
of odd `test` styles that aren't well documented (like using the "x" prefix
to avoid testing empty strings).

>       AC_MSG_WARN([ancient id detected; assuming current UID is ok, but dist-ustar might not work])
> 
> "Might"? Either it works or it doesn't? Anyway, who ever uses ustar?
> Never seen it.

we won't know whether it works until we actually try to create an archive.
and depending on the system, that might be too late (see below).

> Anyway, seems like such a warning "might" be useful when producing an
> archive with automake (running make dist), but not when running
> configure. When merely doing "./configure && make", ustar is irrelevant.

sure, but we don't probe tools during `make dist`, we do it during configure

> Anyway #2, I think the chances of someone wanting to produce a ustar
> archive on a system with old id is zero.
> 
> Thus I suggest just fixing the syntax stuff and letting it go at that. 

ustar might not be the most common nowadays.  i think there's merit to
issuing a warning so we aren't in the situation of people reporting bugs
that `make dist` threw a weird error they don't understand, and if their
system was in such a bad state, why weren't they warned about it ?  in
fact, isn't that what led to these checks in the first place ?  we have
reports from users:
https://bugs.gnu.org/8343
https://bugs.gnu.org/13588

>     the point of the checks isn't just to annoy the user.
> 
> No :)? That's what it seems like. Helpful to the package developer;
> annoyance to the configure user. -k

configure user can (re)create dist tarballs too.  not the common flow, but
it can be helpful when you're hacking on a system and want to pull the state
back out.  or when trying to comply with the GPL requirements :).

the reason your system hit this code path is because it wasn't able to handle
the formats earlier in the list (gnutar in this case).
-mike

[signature.asc (application/pgp-signature, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.