Re: installworld error (makewhatis signal 11)

From: Tomoaki AOKI <junchoon_at_dec.sakura.ne.jp>
Date: Tue, 01 Sep 2026 23:52:22 UTC
On Tue, 01 Sep 2026 18:37:32 +0200
Dag-Erling Smørgrav <des@FreeBSD.org> wrote:

> Tomoaki AOKI <junchoon@dec.sakura.ne.jp> writes:
> > Dag-Erling Smørgrav <des@FreeBSD.org> writes:
> > > Tomoaki AOKI <junchoon@dec.sakura.ne.jp> writes:
> > > > It would be nice if UPDATING has an entry whenever clean builds are
> > > > required, with the reason why for future records.
> > > That would be a huge step backward since our goal is to never need a
> > > clean build.  We have a script (depend-cleanup.sh) which is supposed to
> > > automatically clean either part of or the whole object tree when needed.
> > If it's always maintained to work flawlessly just-in-time.
> 
> Same goes for your UPDATING suggestion.  Someone has to do it.  If
> Someone is going to to Something, adding an entry to depend-cleanup.sh
> is more useful than adding an entry to UPDATING, and not much harder.
> 
> DES
> -- 
> Dag-Erling Smørgrav - des@FreeBSD.org

Would be a bit different.

For UPDATING, I think any committer who noticed the regression
can add warning even if cannot take enough time to
fixup depend-cleanup.sh, while depend-cleanup.sh should be
fixed by the committer of the offending commit (or dedicatedly
assigned specific committers).

In this kind of cases, UPDATING entry isn't needed to be
100% precise. Something like

Upgrading from commit aaaaaaaaaaaa to commit bbbbbbbbbbbb
requires clean full build.

is meaningful enough, and any committer who had enough time
to bisect can narrow down the range until the fixup of
depend-cleanup.sh is finished and committed.

And if there's another committer bitten on upgrading from
commit cccccccccccc (in between commit aaaaaaaaaaaa and
commit bbbbbbbbbbbb) and commit dddddddddddd (after commit
bbbbbbbbbbbb), the committer can fix the range with
commit cccccccccccc to commit bbbbbbbbbbbb.


This kind of rough informations are still quite helpful.

Regards.

-- 
Tomoaki AOKI    <junchoon@dec.sakura.ne.jp>