[PATCHv8] nss_db: protect against empty mappings

[Carlos O'Donell]

On 7/12/19 4:19 PM, DJ Delorie wrote:
> "Carlos O'Donell" <carlos@redhat.com> writes:
>> I wonder if we can't make the workflow different, an this is purely
>> a psychological thing:
>>
>> (a) Make a "build done" stamp.
> 
> What build?  What targets?  There are a lot of installable bits in the
> testroot that can be built independently.  Without a fully
> dependency-driven install, it's very hard to detect that "something
> changed" which would require a re-install.

I don't think we need a fully dependency-driven install.

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.

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

> Of course, we could check for libc.so itself being newer than
> install.stamp, and maybe libm.so if it had containerized tests.

Given Florian and Rafal's feedback I think we need to do something
to make this easier to use.

(1) Top-level make / Top-level make check.

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

(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
   - Top-level stamp is mismatched to chroot stamp but
     subdir make check doesn't reinstall chroot.
   - 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'

Does that make sense?

>> (b) Compare "build done" stamp with "chroot stamp" and if they are
> 
> I suspect this could be centralized into the support routines that
> handle exit codes; looking at "/install.stamp" and some other file.
> Aside from the problem of reliably creating the "some other file", which
> would have to be inside the container also.

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.

This way the user must take a proactive step, the costly one, to bring
the container inline with the recent build. We have argued that doing this
automatically is what's costly, and many times useless if you're just
updating a test case over and over to get it working against a fixed glibc.

-- 
Cheers,
Carlos.