Removing nss overlay ("nssov") from openldap, pre/postinst considerations

[Andreas Hasenack]

I just did a do-release-upgrade with slapd from my ppa which exits 1
in slapd.preinst when it detects the nssov in use, and the release
upgrader crashed, giving the option to send a report. Note this test
doesn't have a debconf critical prompt, I don't know if that would
have changed anything.

On Fri, May 22, 2020 at 10:57 AM Andreas Hasenack <andreas at canonical.com> wrote:
>
> Hello,
>
> On Fri, May 22, 2020 at 10:45 AM Robie Basak <robie.basak at ubuntu.com> wrote:
> >
> > On Fri, May 22, 2020 at 02:27:48PM +0100, Robie Basak wrote:
> > >          We implemented a least-worst solution there, involving IIRC a
> > > critical debconf prompt. I don't remember the details, but that might be
> > > relevant.
> >
> > Looks like we made the maintainer scripts exit with a success code, but
> > we always present a debconf critical note first if we haven't been able
> > to complete. IIRC, we thought that this would be better than breaking a
> > release upgrade. I think this is limited to dealing with things already
> > being broken though - for every other type of problem we do exit
> > non-zero as normal.
> >
> > It might still be a reasonable pattern to follow if we can't come up
> > with anything better.
>
> The maintainer scripts in the package itself already have some cases
> like this, but always followed by a critical prompt. For example, in
> slapd.preinst:
> (...)
>     db_input critical slapd/ppolicy_schema_needs_update || true
>     db_go || true
>     db_get slapd/ppolicy_schema_needs_update
>     if [ "$RET" = 'abort installation' ]; then
>         db_stop
>         exit 1
>     fi
> The above is similar to what I tested, and you would end up with
> having some of the binary packages from src:openldap packages updated,
> but not the bin:slapd package. It's also handling a case where a
> modification is needed. In fact, in this "hook" is where I inserted my
> "exit 1 in preinst" test for the nss overlay removal.
>
> I don't know how the above behaves in a release upgrade either. I'm
> about to test my change (but without the debconf critical prompt) in a
> release upgrade. I assume such prompts are disabled by
> do-release-upgrade anyway.