Installing mariadb-server-5.1 fails when upgrading from mysql with different innodb_log_file_size and replacing /etc/mysql/my.cnf

I upgraded an Ubuntu 8.04 mysql-server-5.0 to mariadb-server-5.1 (5.1.39-ourdelta67). When asked, I choose to install the version of /etc/mysql/my.cnf from the new package, replacing my own.

The install failed, since the old mysql config used a non-default value for innodb_log_file_size. InnoDB refuses to start when the size in .cnf is different than actual size of logs on disk.

Now this situation is actually user error. I am not sure the package should try to be clever and automagically handle a non-default innodb_log_file_size. A user that changes this should be aware of the consequences. I feel uncomfortable with alternatives like trying to pick out the value from the old config and setting in the new one, or deleting the old innodb log files during install.

However, I think we could still improve this situation for the user, by at least allowing the install to succeed, even if the server will then not be able to start until the .cnf is fixed. Currently, the mysqld --bootstrap commands needed to update system tables etc. fails, leaving a broken install that must be fixed with apt-get install --fix-broken or similar.

I suggest to make this more robust by running the mysqld --bootstrap commands with innodb and pbxt disabled:

    MYSQL_BOOTSTRAP="/usr/sbin/mysqld --bootstrap --user=mysql --skip-grant-tables --innodb=OFF --pbxt=OFF --default-storage-engine=myisam"

This should allow install to succeed. The user would not have to fix a broken package install (but still need to fix the my.cnf before being able to start the server, of course).