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
Following Lucasz's shift, here is the status after the next shift. I'm not
summarizing the status here in the email, but reviving the old wiki page, and
added Lucasz's open items (which are still open after my shift). See
https://wiki.ubuntu.com/PlusOneMaintenanceTeam/Status
The wiki page
