Re: install/56303: On a fresh installation, /tmp on sparc64 is not sticky

[Andreas Gustafsson <gson%gson.org@localhost>]

The following reply was made to PR install/56303; it has been noted by GNATS.

From: Andreas Gustafsson <gson%gson.org@localhost>
To: RVP <rvp%SDF.ORG@localhost>
Cc: gnats-bugs%netbsd.org@localhost,
    martin%netbsd.org@localhost,
    roland.illig%gmx.de@localhost,
    Izumi Tsutsui <tsutsui%ceres.dti.ne.jp@localhost>,
    vezhlys%gmail.com@localhost
Subject: Re: install/56303: On a fresh installation, /tmp on sparc64 is not sticky
Date: Fri, 20 Aug 2021 11:04:35 +0300

 RVP wrote:
 > Re: progress.c 1.24: This test which you modified is not needed:
 > 
 >  	if (deadpid == -1 && errno == EINTR)
 >  		continue;
 > 
 > By ths point all read/writes have finished, and `outpipe[1]' has
 > been closed. So you can stop the progress bar code right after the
 > `while (1)' loop and no interrupts can occur. This is what my
 > initial patch did.
 
 Closing outpipe[1] eliminates one source of signals, but I don't see
 any obvious way of proving that there can be no others.
 
 > The subsequent patch is more of the same: dotting
 > the Is and crossing the Ts--very straight-forward stuff, but I
 > wanted to ensure that progress(1) exited with a proper error code
 > everytime.
 
 And, it appears, to do various unrelated cleanups at the same time.
 Don't get me wrong, cleanups are welcome, but lumping them all
 together in a single patch, or even a wholesale replacement of the
 entire source file, makes them hard to review and to separate into
 individual commits with appropriate commit messages.
 
 For example, you are replacing a call to ioctl(TIOCGSIZE) by
 tcgetwinsize(), but it is not clear to me _why_ that change is being
 made, and no developer should commit changes whose purpose they don't
 understand.
 -- 
 Andreas Gustafsson, gson%gson.org@localhost