Hello,
On Fri, May 22, 2020 at 10:45 AM Robie Basak <robie.ba...@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.
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
