Comment 17 for bug 1725222

> Seems they identified the issue causing the upgrade to fail: https://support.plesk.com/hc/en-us/articles/115003430813#_=_

So it looks like the configuration option innodb_additional_mem_pool_size was valid in MySQL 5.5 but is no longer valid in MySQL 5.7? AFAICT, that configuration option was not shipped in any packaging previously. Is the problem that for users who have customised their system configurations with this option (or for example some third party tool has done it), a subsequent release upgrade to 5.7 will fail?

See bug 1571865. Upstream does not provide a script which can automatically convert every single possible configuration customisation in MySQL 5.5 with an updated equivalent version in MySQL 5.7. So distributions cannot reasonably be expected to be able to provide such an automated upgrade path either. This is standard behaviour across all distributions I believe. Distributions allow you (or a third party working on your behalf) to customise your installations to the extreme. However, there is no practical automatic upgrade path that works in all cases and can be provided when upstream semantics change in a release upgrade.

So I cannot consider this to really be a bug in MySQL packaging.

If, separately, you want to provide a smoother upgrade path in a maintainer script for a specific customisation, then we'll happily accept that patch. Providing that the patch can be shown to likely not make anything worse in any possible use case. If you want to do this, then please file a specific bug for the specific customisation (or set of customisations) upgrade path you want to fix. Please don't use a generic "it doesn't work" bug like this one has become as that just results in confusion with all of the "me too" people involved in this bug who may be affected by the general issue but not your particular and specific customisation.