On Fri, May 22, 2020 at 10:57:23AM -0300, Andreas Hasenack wrote:
> 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.
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
Hello,
On Fri, May 22, 2020 at 10:45 AM Robie Basak 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.
>
>
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
Hello, thanks for your feedback
On Fri, May 22, 2020 at 10:27 AM Robie Basak wrote:
> > One of the options outlined
> > in [4] is an exit 1 in preinst. That would leave the previous package
> > installed, the daemon running, and the original
On Thu, May 21, 2020 at 05:25:46PM -0300, Andreas Hasenack wrote:
> Is there any pattern, or precedence, in Ubuntu or Debian, of where a
> package upgrade removes a piece of the software and it cannot be
> easily handled in the maintainer scripts?
Unfortunately this is an area for which I don't
Hi,
I would like to stop building the nss overlay in openldap[1][2], and
proposed a change[3] for that.
One of the comments I got from the Debian Maintainer is that this
would break an upgrade for whoever was using that module, as slapd
(the daemon) would refuse to start if the module is
