Re: Bmake bad variable name

[Composed last night but accidentally not sent.]

This is about some of the new text in:

http://www.zefox.net/~fbsd/poudriere_on_rpi4



I originally took the "To set up poudriere, use" and
"Next, construct one jail," as per-version upgrade
activity, not notes about starting from scratch the
first time. I understand now after also reading the
later text that has a variation of some of the
earlier material. Interpreting my prior message of
notes for what I was (incorrectly) thinking requires
deliberate use of my misinterpretation as context.
Sorry. But one things that contributed to the
misinterpretation was:

QUOTE
# make -DBATCH_DELETE_OLD_FILES delete-old DESTDIR=/usr/local/poudriere/poudriere-system DB_FROM_SRC=1
# make -DBATCH_DELETE_OLD_FILES delete-old-libs DESTDIR=/usr/local/poudriere/poudriere-system DB_FROM_SRC=1
END QUOTE

Those 2 commands suggest that

/usr/local/poudriere/poudriere-system

may have had a prior build in it to clean out
old material from.



The line "cd /usr/local/poudriere" is still there.

For some reason you have:

# cd /usr/src
# make installkernel DESTDIR=/usr/local/poudriere/poudriere-system DB_FROM_SRC=1
# make installworld DESTDIR=/usr/local/poudriere/poudriere-system DB_FROM_SRC=1

vs. (different order)

make -j4 installworld DESTDIR=/usr/local/poudriere/poudriere-system DB_FROM_SRC=1 > poudup.log && \
make -j4 installkernel DESTDIR=/usr/local/poudriere/poudriere-system DB_FROM_SRC=1 >> poudup.log && \

When not updating the live boot media's live kernel the
ordering does not matter. But it does for updating the
running system's materials: Unless one is tracking
detailed dependencies of world on new kernel ABI changes,
the order of the installs for the booted system (self
updating) should be:

installkernel
reboot so the updated kernel ABI is available for the new world to use
etcupdate -p [so that installworld has access to potential new things]
installworld
etcupdate -B
make delete-old
reboot yet again so that no old world code is still executing

SOMETIME LATER when the old libraries are no longer used
by any installed ports: make delete-old-libs

Note: the -B in "etcupdate -B" is only appropriate if the
buildworld for the source code update was done previously:
-B leads to using data from the build instead of having to
regenerate that data for its own use.

The other order (installworld installkernel) can lead to
executing world programs that depend on the new ABI when
it is not available yet: after installworld new process
creations execute the new world code is executed even if
you do not reboot. (dynamic loading also picks up the new
materials.)

In other words:

QUOTE
installscript contains:
make -j4 installworld > installworld.log && make -j4 installkernel KERNCONF=GENERIC > installkernel.log && etcupdate > etcupdate.log && ./poudriereupscript
END QUOTE

seems odd for its installkernel vs. installworld ordering,
as well as its etcupdate details.

(The build order is buildworld then buildkernel instead:
buildworld puts some things in place for buildkernel to
use.)



A transition from 15.0-CURRENT to 15.0-ALPHA1 also needs
a jail update. But it would produce a different message
than the error message that started this investigation.
Going from 14 -> 15 does have some activity that is a
unique to that renumbering but that activity is not the
only reason that the jail update is appropriate for
a change in the text. Other messages are possible as
well.

(It can simplifying things to wait and do the likes
of 14.0-CURRENT -> 15.0-CURRENT without ever going
through a 14.0-ALPHA* stage. ALPHA* changes the version
text weekly.)

This contributes to:

QUOTE
Occasionally FreeBSD's version will increment so the jail has to be updated.
I ended up deleting and re-creating the jail with the new -v value.
END QUOTE

being incomplete in its coverage (unless CURRENT -> ALPHA1 or
the like are valid "increment"s).



The "FreeBSD:" in /usr/local/etc/pkg/repos/FreeBSD.conf
has a tab in front. But the "enabled: no" has spaces.


I'll note that later poudriereupscript material does
not suggest to ever have a delete-old-libs executed.
Leaving old libaries around can lead to some being
used when they should not be during port -> package
building. But delete-old-libs may need to be later,
only after the old library referencing ports have
all been rebuilt into new packages, unless
one first does something like:

# poudriere pkgclean -jmain -A

so there is nothing around that might try to use the
older library materials. This is not usually an issue
but when certain system libraries are updated to no
longer be backwards compatible for older port builds
to use (ABI/API changes), one hss to be sure that
every use gets replaced with new build materials. I'll
note that for main, for example, this can happen
without a ??.?-???? textual change at the time.


For:

QUOTE
After world/kernel update one must repeat the steps in /usr/src.
It's convenient to place in /usr/src a few small scripts with
the desired commands:
END QUOTE

Which steps? For example, doing another git pull (or fetch
then merge --ff-only sequence) would not be appropriate.

I expect that you mean just the steps that involve:

make . . . DESTDIR=/usr/local/poudriere/poudriere-system . . .


QUOTE
For example, apache24script contains
poudriere bulk -j main www/apache24 > apache24.log
Redirecting output and running the command in the background
ensures the job won't stop if the controlling terminal gets
disconnected.
END QUOTE

If I understand right, a SIGHUP signal might still be
possible for the controlling terminal ending up
disconnected, even for the background processes. It
might be that nohup use is required to avoid that in
some contexts.

Also, you only show redirection of stdout, not of stderr .

===
Mark Millard
marklmi at yahoo.com