Re: Removing nss overlay ("nssov") from openldap, pre/postinst considerations
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. They are definitely not disabled by do-release-upgrade. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Removing nss overlay ("nssov") from openldap, pre/postinst considerations
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 wrote: > > 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. > > > > 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
Re: Removing nss overlay ("nssov") from openldap, pre/postinst considerations
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. > > 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
Re: Removing nss overlay ("nssov") from openldap, pre/postinst considerations
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. signature.asc Description: PGP signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Removing nss overlay ("nssov") from openldap, pre/postinst considerations
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 functionality there, > > but the admin then has to take action as the upgrade was done half-way > > (libraries were updated, but the daemon package remains at the > > previous version). > > What would happen in the do-release-upgrade case? Would the upgrade fail > at the start (not so bad), or in the middle (really bad)? Because the > preinst won't necessarily run at the start of the release upgrade - only > at the start of a batch of package upgrades - right? I don't know, I can test that scenario. -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Removing nss overlay ("nssov") from openldap, pre/postinst considerations
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 think we've ever found a satisfactory solution. I think it's important that if an upgrade does have to leave something broken, then the user is aware of it. So some maintainer script somewhere should fail. However... MySQL packaging faced a similar because packaging does a schema upgrade but that cannot be done if mysqld cannot be started - for example if it if the database is broken with mysqld already not running before the upgrade. We implemented a least-worst solution there, involving IIRC a critical debconf prompt. I don't remember the details, but that might be relevant. > 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 functionality there, > but the admin then has to take action as the upgrade was done half-way > (libraries were updated, but the daemon package remains at the > previous version). What would happen in the do-release-upgrade case? Would the upgrade fail at the start (not so bad), or in the middle (really bad)? Because the preinst won't necessarily run at the start of the release upgrade - only at the start of a batch of package upgrades - right? signature.asc Description: PGP signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
