[debian] Introducing default-mysql-* metapackages

3 views
Skip to first unread message

PICCA Frederic-Emmanuel

unread,
Sep 3, 2016, 3:37:23 AM9/3/16
to ta...@esrf.fr, debian-pan-...@lists.alioth.debian.org
Hello Tangoers,

Here an email received from the pkg-mysql-maint Team from Debian.

It explains that mariadb will be the default instead of mysql for
Debian Stretch (aka Debian 9)

for now only tango8 is part of debian/ubuntu, tango9 is available in
the experimental release.

My questions are.

1) is tango-db (8 and 9) compatible with mariadb ?

by compatible I mean the setup scripts of tango8 and tango9 work
out of the box with mariadb. all the upgrade scripts available in
the package (debian/mysql/*) are working out of the box in order
to have a smooth upgrade for our users.

2) should we switch to the default-* mecanism

It seems that there is a problem with these scripts on mysql-5.7,
so maybe also with mariadb.

I do not have the time myself to take care of this, BUT I can sponsor
your work.

3) which version of tango do you want in debian/ubuntu ?

Work required in order to have:
* tango8

- adapt all the sql scripts to the new mysql/mariadb version

- support tango8 for the next release ;) (do not forget the
Long time support LTS effort)

* tango9

- adapt all the sql scripts to the new mysql/mariadb version

- upload pytango9

- upload itango

thank to the work done by Bodó-Merle Sándor from ELI-APLS these two
last packages are almost ready. (Big thanks) I will upload pytango9
into experimental this week-end, and itango in the near future.

Indeed all this should be tested.

Just for information, the dead line for this to happend for Debian
Stretch is close. In november no more transition will be allow by
the Release Team. So to my opinion, all this should be finished
before the end of September.

Thanks for your attention.

Frederic on the behalf of the Debian-Pan team.

PS: Crossposting to debian-pan-maintainers

________________________________________
De : pkg-mysql-maint [pkg-mysql-maint-bounces+picca=synchrotro...@lists.alioth.debian.org] de la part de Otto Kekäläinen [ot...@debian.org]
Envoyé : samedi 3 septembre 2016 08:41
À : debian-dev...@lists.debian.org
Cc : nt...@debian.org; Paul Gevers; pkg-mysql-maint
Objet : [debian-mysql] Introducing default-mysql-* metapackages

Hello maintainers of packages that depend in MySQL/MariaDB!

TL;DR;

Please update packages that depend on MySQL or MariaDB as follows:

BEFORE: Build-Depends: libmysqlclient-dev
AFTER: Build-Depends: default-libmysqlclient-dev

BEFORE: Depends: mysql-server | virtual-mysql-server
OR Depends: mariadb-server | virtual-mysql-server
AFTER: Depends: default-mysql-server | virtual-mysql-server

BEFORE: Depends: mysql-client | virtual-mysql-client
OR Depends: mariadb-client | virtual-mariadb-client
AFTER: Depends: default-mysql-client | virtual-mysql-client


Details follow:

The release team decided earlier in the spring that MariaDB should be
made the default MySQL variant in Debian. The release team also wished
to have a facility that allows easy switching of the default.

Therefore we have introduced the following metapackages
from the mysql-defaults source package:
- default-mysql-server
- default-mysql-server-core
- default-mysql-client
- default-mysql-client-core
- default-libmysqlclient-dev

All maintainers of packages that currently depend directly on
mysql-server, mariadb-server, or any of the other packages in these
series, shall update the dependencies in their packages to point to
default-mysql-* instead.

Installing the metapackage default-mysql-server will pull in
mariadb-server-10.0. Users who had mysql-server-5.6 will have it
removed and replaced by the MariaDB equivalent on upgrade. Note that
once you have switched to MariaDB, it might not possible to convert
your in-place database files back to MySQL automatically, since Oracle
does not maintain tools to convert possible MariaDB features present
in the binary format. Please back up your data first if you wish to
switch or experiment. Manual dump/import is the most reliable way to
import data from one installation to another.

A virtual package scheme virtual-mysql-* already exists since 2013,
and will continue to exist. All MySQL variants in Debian (and outside
in 3rd party repositories too) have Provides for these virtual-mysql-*
packages. Maintainers can must use "Depends: default-mysql-server |
virtual-mysql-server" if their package can be satisfied by any MySQL
variant (Oracle, MariaDB, Percona, mysql-wsrep).

The first dependency should be default-mysql-*, which is a
metapackage, that in turn depends on exactly one option, which for now
is MariaDB.

If a maintainer knows that his/her package only works with one
variant, then the package can depend directly on that package and not
use the default-mysql-* (matches one) or virtual-mysql-* (matches any)
schemes. Please get in touch if this applies to you. At the moment
there should be no such packages, but in the future cases like this
can arise when MySQL and MariaDB develop diverging feature sets.

Packages built against default-mysqlclient-dev and link using
"-lmysqlclient" will end up with a shared library dependency on either
libmysqlclient.so.X or libmariadbclient.so.X depending on the default
defined by the release team at build time. These will be provided by
the libmysqlclient18 (soon to be libmysqlclient20) and
libmariadbclient18 packages, which will be co-installable. Packages
which require particular functionality available from only one of the
forks may Build-Depend directly on libmysqlclient-dev or
libmariadbclient-dev and then link using "-lmysqlclient" or
"-lmariadbclient" respectively. Again, please get in touch if this
applies to you.

Users that want to rebuild packages against a different variant of
lib*client-dev for experimenting and testing locally should prefer
using a locally modified default-libmysqlclient-dev over modifying
each client application source package individually.

The default-mysql-* metapackages have been available in experimental
since July, and since also in unstable and testing, and we are
confident there are no regressions. If you however do encounter
problems, please report to pkg-mysql-maint@.


On behalf ot the pkg-mysql team,

- Otto

_______________________________________________
pkg-mysql-maint mailing list
pkg-mys...@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-mysql-maint

message-footer.txt

rp

unread,
Sep 3, 2016, 10:01:25 AM9/3/16
to PICCA Frederic-Emmanuel, ta...@esrf.fr, debian-pan-...@lists.alioth.debian.org
thanks for the hard work !
does it include ARM support, especially rasperrypi 2/3 armhf processor (at least required libraries packages to link device server code) ?

regards

De : pkg-mysql-maint [pkg-mysql-maint-bounces+picca=synchrotron-soleil.fr@lists.alioth.debian.org] de la part de Otto Kekäläinen [ot...@debian.org]

Envoyé : samedi 3 septembre 2016 08:41
To stop receiving message from ta...@esrf.fr, please send an e-mail to
tango-un...@esrf.fr (subject/content don't matter).




--
a+
raph
message-footer.txt

PICCA Frederic-Emmanuel

unread,
Sep 3, 2016, 10:19:39 AM9/3/16
to rp, ta...@esrf.fr, debian-pan-...@lists.alioth.debian.org
> thanks for the hard work !
> does it include ARM support, especially rasperrypi 2/3 armhf processor (at least required libraries packages to link device server code) ?

indeed all the architectures of Debian/Ubuntu/... are affected.

amd64, arm64, armel, armhf, i386, mips, mips64el, mipsel, powerpc, ppc64el, s390x, alpha, hppa, hurd-i386, kfreebsd-amd64, kfreebsd-i386, m68k, powerpcspe, ppc64, sparc64 and x32

Cheers

Frederic
message-footer.txt

Vincent Hardion

unread,
Sep 3, 2016, 11:11:15 AM9/3/16
to rp, PICCA Frederic-Emmanuel, ta...@esrf.fr, debian-pan-...@lists.alioth.debian.org
Hi,

Just to tell you that we use Maria db from last january since we move to Centos 7 and it works fine. For tango8 there is a small patch for the timestamp format.

We just upgraded to tango 9 and found a minor issue with the order of timestamp definition. A patch should come soon 😊

Cheers,
Vincent 



Sent from my Samsung device
message-footer.txt

PICCA Frederic-Emmanuel

unread,
Sep 3, 2016, 11:15:48 AM9/3/16
to Vincent Hardion, rp, ta...@esrf.fr, debian-pan-...@lists.alioth.debian.org
Hello vincent,

can you attach your patch to a tango bug on sourceforge ?

this way It will be possible to understand the fix and propagate it to all the migration scripts.

thanks

Fred

message-footer.txt

Vincent Hardion

unread,
Sep 3, 2016, 3:58:57 PM9/3/16
to PICCA Frédéric-Emmanuel, rp, ta...@esrf.fr, debian-pan-...@lists.alioth.debian.org
Issue 815 on source forge with the patch.

Good luck with debian,
/Vincent
message-footer.txt

PICCA Frederic-Emmanuel

unread,
Sep 3, 2016, 4:11:35 PM9/3/16
to Vincent Hardion, rp, ta...@esrf.fr, debian-pan-...@lists.alioth.debian.org
Hello vincent,

is it compatible also with mysql < 5,7 ?

Cheers

Fred
message-footer.txt

Vincent Hardion

unread,
Sep 3, 2016, 4:25:08 PM9/3/16
to PICCA Frédéric-Emmanuel, rp, ta...@esrf.fr, debian-pan-...@lists.alioth.debian.org
Apparently yes since there still only one default timestamp

  • In MariaDB 5.5 and before there could only be one TIMESTAMP column per table that had CURRENT_TIMESTAMP defined as its default value. This limit has no longer applied since MariaDB 10.0.
In mysql 5.6: The order of the clauses does not matter 
To specify automatic properties, use the DEFAULT CURRENT_TIMESTAMP and ON UPDATE CURRENT_TIMESTAMP clauses in column definitions. The order of the clauses does not matter. If both are present in a column definition, either can occur first. Any of the synonyms forCURRENT_TIMESTAMP have the same meaning as CURRENT_TIMESTAMP. These are CURRENT_TIMESTAMP()NOW()LOCALTIMELOCALTIME(),LOCALTIMESTAMP, and LOCALTIMESTAMP().

The best is to try but I don’t have mysql < 5,7

/Vincent
message-footer.txt
Reply all
Reply to author
Forward
0 new messages