Re: [PATCHv8] nss_db: protect against empty mappings

[DJ Delorie <dj at redhat dot com>]

"Carlos O'Donell" <carlos@redhat.com> writes:
> I don't think we need a fully dependency-driven install.

My point was, it's difficult to tell if an arbitrary "make" invokation
warrants a re-install - doing that would imply a full set of
dependencies about what *is* installed, and at that point, we have a
dependency-driven install anyway.

But that's a distraction at this point ;-)

> We need:
>
> * One stamp to be created when a top-level invoked 'make' finishes
>    building anything. Sub-makes don't update this stamp so running
>    them leaves the top-level 'make' stamp at the old time.

It would be easier to do something at the start, using a := rule and
$(system) but GNU make might have more options by now.

> * One stamp to be created when the chroot is installed.

that would be testroot.pristine/install.stamp :-)

> * User runs 'make' at the top-level (not a subdir)
>    - Top-level stamp is updated.

Only "make" - no parameters?  I mean, the default target?  I suppose
that would be an obvious point to flag most cases.

> * User runs 'make check' at top-level (not a subdir)
>    - Top-level stamp is mismatched to chroot stamp and so we
>      reinstall the root.

Or just making the default target could remove
testroot.pristine/install.stamp, which would case "make check" to redo
the install anyway.

> (2) Top-level make / subdir make check.
>
> * User runs 'make' at the top-level (not a subdir)
>    - Top-level stamp is  updated.
> * User runs 'make check' in a subdir

The testroot install dependency is on the subdir checks, not the
toplevel check, anyway, so this isn't a different case as far as the
testroot is concerned.  I.e. the Makefile does this:

$(tests-container) $(addsuffix /tests,$(subdirs)) : \
		$(objpfx)testroot.pristine/install.stamp

>    - Top-level stamp is mismatched to chroot stamp but
>      subdir make check doesn't reinstall chroot.

Faster :-)

>    - test-container throws a warning telling the user how
>      to fix this, but ignores it, runs the test, and always
>      returns a new error code.
>    - Developer is *able* to run the subdir test with failure
>      mode "root not in sync", but that might be fine for them.
>      They can look at the original logs and original failures.
>    - Developer can choose now to do a top-level make check to
>      trigger root re-install, or convenience target 'make update-container'

I think this is dangerous for two reasons...

1. We're hiding testing-specific details inside test-container.c, which
   otherwise is only concerned with the containerization itself.

2. Any text other than the PASS/FAIL/etc lines should be assumed ignored
   by any script that parses the output, or by developers who
   auto-filter-out everything else because "it's never relevent".

I would suggest that the out-of-date flag be something that the support
code can detect, and replace any PASS/FAIL/etc with UNSYNC or something
that sticks out like a sore thumb.  Or perhaps append " - UNSYNC[*]" to
the end of that line, and adds a footnote elsewhere which the developer
can look for once the UNSYNC is noticed.

I don't know how easily it would be to robustly detect "I'm in a
testroot container" but if it looks for /install.stamp and /build.stamp
(i.e. in the root dir) that should suffice.

We could, however, have test-container.c set TESTROOT_CONTAINER=1 in the
child's environment, just for such detection.

The only other alternative I think would make sense is if
test-container.c detected an out-of-sync container, and just
hard-stopped.  I.e. don't run anything.  I don't know how this could be
made to show up in the PASS/FAIL text though, so that it's noticed.  I
worry that it would go unnoticed that a subset of tests just aren't
being run at all.

> I would check the stamps in the build and pass test-container a new
> flag e.g. --out-of-date, if the stamps don't match, and let test-container
> decide what to do.

test-container has nothing to do with the tests; it merely runs a given
binary and echos the exit code.  It's the runtime test harness that is
aware of what the tests mean.  The coordination needs to be between the
toplevel Makefile and support/test-driver.c et al.