Re: Etcupdate runtime has more than doubled....Why?

On 4/1/26 12:10, Mark Millard wrote:
> On 4/1/26 11:34, bob prohaska wrote:
>> On Wed, Apr 01, 2026 at 11:00:56AM -0700, Mark Millard wrote:
>>>>
>>>
>>> etcupdate has the option:
>>>
>>>
>>> -B            Do not build generated files in a private object tree.
>>>               Instead, reuse the generated files from a previously built
>>>               object tree that matches the source tree.  This can be
>>>               useful to avoid gratuitous conflicts in sendmail(8)
>>>               configuration files when bootstrapping.  It can also be
>>>               useful for building a tarball that matches a specific
>>>               world build.
>>>
>>>
>>> So, if one already has the required context, its use might be relevant.
>>> Of course, without the proper context, it should not be used.
>>>
>>> What was the context-status and use vs. not for -B ?
>>
>> There's only one /usr/obj on the system.
>>
>> The buildworld command used was
>> make -j3   KERNCONF=GENERIC  TARGET=arm TARGET_ARCH=armv7 buildworld
>> and the etcupdate command following buildworld was
>> etcupdate -p
>>
>> After installing world and kernel, etcupdate runs again as
>> etcupdate
>>
>> Might using etcupdate -B in the second invocation be a remedy?
> 
> Extracted/simplified from my more overall scripts full of local details:
> 
> # make WITH_META_MODE=yes buildworld
> # make WITH_META_MODE=yes buildkernel
> # etcupdate -p
> # etcupdate resolve -p
> # make WITH_META_MODE=yes installkernel

Note for live updating the booted file system:

# # Possibly: vi /boot/loader.conf
# shutdown -r now
. . .

(I have contexts that do not involve that.)


> # make WITH_META_MODE=yes installworld
> # etcupdate -B
> # etcupdate resolve
> # make delete-old check-old
> # #AS NEEDED for timing?: make delete-old-libs
> # etcupdate status

Note for live updates the booted file system or just wanting to:

# # Possibly: vi /boot/loader.conf
# shutdown -r now
. . .

(I have contexts that do not involve that. For those I may deal with
booting at some later time for some other reason.)

> 
>>
>> Thanks for writing!
>>
>> bob prohaska
>>
>>
>>
> 
> 


-- 
===
Mark Millard
marklmi at yahoo.com