Re: [PATCHv8] nss_db: protect against empty mappings

[Carlos O'Donell <carlos at redhat dot com>]

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.