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