[debian-mysql] My issues with the structure of the mysql-5.5 package

Nicholas Bamber nicholas at periapt.co.uk
Thu May 17 23:47:53 UTC 2012


Various issues have forced me to seriously question whether the
Debian MySQL package has the right structure. This is an entangled
set of issues so please bare with me. I have tentative opinions but
no certainty and in any case this is exactly the sort of issue that
needs discussion. It goes without saying that nothing in this email
will make it into wheezy.

Background
----------

* Various bug reports, (#660087, #317934, #511438), call for the package 
to be further split up. I don't see how any one person can make a 
decision on these sort of issues but I for one am sympathetic to the 
views expressed there.

* Some executables, e.g. innochecksum, are in different packages
from their man pages.

* There seems to be no coherent definition of what is client side and 
what server side. I would have thought a MySQL client is an executable 
that only requires a TCP connection to the MySQL server. On this basis 
there are executables in the wrong package in both directions.

* Some setups (for example simple websites) may only require MyISAM 
support. Others (for example highly transactional systems) may have no 
need for MyISAM.

* The test suite largely consists of non executable ASCII files. We 
could split this into an arch:any core and an arch:all test data.

* Ubuntu has struck out in its own direction and put the mysql and 
mysqlcheck clients into a new mysql-client-core-5.5 package. In 
principle I have no issue with following Ubuntu on this. But I struggle 
to see by what criteria, for example, mysqlcheck was included and 
mysqladmin excluded.

* It is confusing and wasteful for each MySQL package to have its own 
doc directory. Debhelper would help consolidate them. However the 
directory  would have to be physically owned by an arch:any package 
which was required by all the others.

On the other hand, if we split out 'replace' as per ??? we would not 
want it sharing the same docs directory as the rest as that would defeat 
the motivation of the bug report. It would need a separate copyright 
statement.

* ?? also needs to be considered if we rearrange the packages. Ideally 
each package should own its bit of config below /etc/mysql/conf.d

I have documented the issues at ???.

Tentative Suggestions
---------------------
* I propose a radical restructuring of the package. I suggest the actual 
split should be done as soon as possible after the freeze. However 
dependencies that should become Recommends will stay as Depends for now 
to ease the transition.

* The mysql-common package would become arch:any. This package would own 
the shared documentation directory.

* We would have the following

Package                  Depends On
innotop                  n/a [separate source anyway]
replace                  n/a [would have to have separate docs directory]
mysql-common             n/a
mysql-source-5.5         mysql-common
mysql-testsuite-core-5.5 mysql-common
mysql-testsuite-5.5      mysql-testsuite-core-5.5
mysql-testsuite          mysql-testsuite-5.5
libmysqlclient18         mysql-common
libmysqlclient-dev       mysql-common
libmysqld-dev            libmysqlclient18
libmysqld-pic            libmysqlclient18
mysql-client-core-5.5    mysql-common, libmysqlclient18 (via 
libdbd-mysql-perl)
mysql-client-5.5         mysql-client-core-5.5
mysql-client             mysql-client-5.5
mysql-server-core-5.5    mysql-common
mysql-myisam-utils-5.5   mysql-server-core-5.5, replace
mysql-server-utils-5.5   mysql-server-core-5.5
mysql-server-5.5         mysql-server-core-5.5, mysql-server-utils-5.5,
                          mysql-myisam-utils-5.5
mysql-server             mysql-server-5.5

The proposed mysql-server-utils-5.5 package is something of hodge podge. 
I am amenable to saying it should be split up further. But I am not sure 
what the principles are.



More information about the pkg-mysql-maint mailing list