OK, this is way too long, so TLDR: (1) "build.sh -u" can have
unintended consequences for files installed direct from a source file;
and (2) "install -p" is poorly documented.....
So, the other day I was looking for information about a command-line
option for "less" and I noticed the option wasn't even documented in the
manual page.
Then I noticed the "Version 394: 03 Dec 2005" footer on the page and I
thought that couldn't be right.
Sure enough a look at the source showed it should be much newer.
As it turns out I had built and installed versions of NetBSD-5.x on a
couple of my primary production machines prior to upgrading them to much
more recent versions, and as a result there were catman pages installed
on them.
I then discovered that the postinstall(8) handling of catman pages is
not working in certain circumstances until/unless changes are made to the
sources for those manual pages.
For example for less(1), the installed catman page on my two production
machines is dated in 2015 (the date of the last installed NetBSD-5.x
build I used), but the installed source manual page on those machines
(built from a mid-2023 source tree) is dated in 2013. So, postinstall
does not, and cannot, remove the "old" catman page because it's actually
newer than the source manpage! This might remain a problem until 11.0.
I've since noticed that the installed manual pages on official builds
are dated the date of the build, while mine are not.
I finally found the following in <bsd.own.mk>:
.if ${MKUPDATE} == "no"
PRESERVE?=
.else
PRESERVE?= -p
.endif
So.... my builds are almost always done with "MKUPDATE=yes".... even the
first time around....
That would seem to have unexpected consequences for files that are
installed directly from their original source files! Normally files
being installed are build products that have just been created new
during a recent "make", but of course many manual pages are installed
directly from their original source file -- a file that may remain
untouched for many years.
So, this specific issue probably doesn't affect anyone (besides me) any
more, but I wonder if maybe as a matter of good principal that maybe
something a bit smarter should be done about use of "install -p" for
files that are not build products.
I've always felt uncomfortable about installing "source" files directly
into a destdir and would prefer to have an intermediate product file,
even if it is just a plain copy (i.e. into the objdir); but on the other
hand this seems wasteful of build resources and for a project the size
of NetBSD may be too much to enforce.
As an alternative one could of course arrange to avoid allowing the '-p'
to be used when installing files that are copied directly to destdir
from their source file.
Another way to ensure the installed file looks current in the destdir
even if '-p' is used would be to simply touch it after install, and
doing this would still have very little impact on build resources.
Only the first option is simple enough to be agnostic of "install -p"
and not require too much extra complexity while at the same time being
easy to detect violations of.
Anyone have any other thoughts?
Also, BTW,, I find the documentation for "install -p" is ambiguous to
the point of being misleading, in part because it has incorrect grammar,
but also just in general. I suggest:
--- install.1.~1.47.~ 2012-11-27 21:00:38.000000000 -0800
+++ install.1 2024-12-28 12:37:56.967641263 -0800
@@ -245,7 +245,7 @@
.It Fl o Ar owner
Specify an owner.
.It Fl p
-Preserve the source files access and modification times.
+Copy the source file's access and modification times to the target file.
.It Fl r
Install to a temporary file and then rename the file to its final destination
name.
--
Greg A. Woods <gwoods%acm.org@localhost>
Kelowna, BC +1 250 762-7675 RoboHack <woods%robohack.ca@localhost>
Planix, Inc. <woods%planix.com@localhost> Avoncote Farms <woods%avoncote.ca@localhost>
Attachment:
pgpw59yw1vrXI.pgp
Description: OpenPGP Digital Signature