[debian-mysql] Managing switches between *-{server|client}-{core|}-x.x variants

Clint Byrum spamaps at debian.org
Sat Mar 1 18:59:41 UTC 2014


Excerpts from James Page's message of 2014-03-01 07:37:20 -0800:
> Hash: SHA256
> 
> Hi Team
> 
> Managing the Breaks/Replaces/Conflicts between the (nearly) four mysql
> options with have across unstable and experimental needs to get a bit
> more intelligent; I had a play around with mysql-5.5, mysql-5.6 and
> mariadb-5.5 today and here is what I propose:
> 
> 1) we manage all file conflicts with Breaks/Replaces - this avoids the
> hardness of Conflicts which as we have discuss in ML and in irc before
> could be an issue during upgrades
> 
> 2) each level of binary package declares an appropriate Provides, e.g.
> 
> mysql-client-core-5.5,mysql-client-core-5.6,mariadb-client-core-5.6:
>      Provides: virtual-mysql-client-core
> 
> mysql-client-5.5,mysql-client-5.6,mariadb-client-5.6:
>      Provides: virtual-mysql-client
> 
> etc...
> 
> 3) each binary package also Breaks/Replaces its Provides:
> 
> mysql-client-5.5,mysql-client-5.6,mariadb-client-5.6:
> 
> Breaks: virtual-mysql-client
> Replaces: virtual-mysql-client
> Provides: virtual-mysql-client
> 
> in the example above, as each *-client-X.X package does the same
> thing, they should just switch in/out OK.
> 
> 4) upgrades from previous releases
> 
> We will need to leave in some Breaks/Replaces - to deal with upgrades
> from the mysql-5.5 version currently in stable as these won't provide
> all of the virtual-* stuff.
> 
> Thoughts?
> 
> If this makes sense to folk I'll take some time to apply and test this
> in full with the three variant we have in archive today.

It makes logical sense to me. I'm curious if we have precedent in other
packages to help us find the gotchyas in this strategy.



More information about the pkg-mysql-maint mailing list