Re: mail/mutt and BDB_ACCEPTED

[Roland Illig <roland.illig%gmx.de@localhost>]

On 07.04.2020 22:12, Rhialto wrote:
> On Tue 07 Apr 2020 at 15:25:18 +0200, Olaf Seibert wrote:
> > It turned out in the end that "../../mk/bdb.buildlink3.mk" was
> > prematuredly included, before BDB_ACCEPTED was set. Indeed it happened
> > as early as somewhere during the
> >
> > .include "../../mk/bsd.options.mk"
> >
> > near the top of the file.
>
> How do other people debug this sort of stuff? The only way I can think
> of is to litter the makefiles with many ".info before FOO" type lines.
> Make's -d options all output way too much crap to be useful.

$ cd mail/mutt
$ pkglint
(... nothing interesting ...)

$ bmake show-all-bdb
bdb:
  usr   BDB_DEFAULT=            db4
  usr   BDB185_DEFAULT=         db1
  pkg   BDB_ACCEPTED=           db4 db5
  sys   BDB_TYPE=               db1
  sys   BDBBASE=                /usr
  sys   BDB_LIBS=               # empty

Given that you had a clue that something with bdb was wrong, this would
have saved you some time already.

When I'm in such a situation, I usually add all variables that are
mentioned in bdb.buildlink3.mk to the _VARGROUPS section, to get a more
detailed picture of the situation:

$ pkglint  ../../mk/bdb.buildlink3.mk

NOTE: ../../mk/bdb.buildlink3.mk:60: BDB_BUILDLINK3_MK can be compared
using the simpler "${BDB_BUILDLINK3_MK} == +" instead of matching
against ":M+".

WARN: ../../mk/bdb.buildlink3.mk:73: Variable USE_DB185 is defined but
not mentioned in the _VARGROUPS section.

WARN: ../../mk/bdb.buildlink3.mk:81: Variable _BDB_PKGS is defined but
not mentioned in the _VARGROUPS section.

After that, by looking at the output of "bmake show-all-bdb" again, the
situation usually becomes easier to understand.

> It turns out that the first time that mk/bdb.buildlink3.mk is included
> is somewhere during
>
> .  include "../../mk/krb5.buildlink3.mk", which does
> .  include "../../security/heimdal/buildlink3.mk", which does
> .include "../../mk/bdb.buildlink3.mk"
>
> It is included a second time from something I didn't trace,
>
> and then finally it is included a 3rd time directly from
> mail/mutt/options.mk.

I could add a check to pkglint that makes this situation an error or at
least a warning. The general rule for this would be:

If some part of a file is guarded from multiple inclusion, and if the
file defines some package-settable variables, these variables must not
be changed after the file has been included for the first time.

Most of the necessary code for this check is already in pkglint. What is
missing is the part about multiple inclusion guards. For that,
bdb.buildlink3.mk is an interesting example because it does not use the
".if !defined(GUARD)" pattern, but instead the ".if !empty(GUARD:M+)",
which could also be written as ".if ${GUARD} == +" more easily. But
that's not all. It includes bsd.fast.prefs.mk outside of the guarded
section, for no apparent reason. And, after the guarded section, there
is some more code. All these are things I wouldn't have expected at first.

Whether a variable is package-settable is currently hard-coded in
pkglint. Up to now, pkglint does not interpret the documentation comment
"Package-settable variables", but it could certainly do so.

I would expect that this check finds not only mail/mutt but also tens of
other packages that have this difficult-to-spot bug.

Roland