Re: [debian-mysql] About packages that depend on mysql-* / mariadb / virtual-mysql-*
On Tue, Jul 05, 2016 at 11:41:15AM +0200, Jonathan Wiltshire wrote:
> > I suggest we extend the mysql-defaults source package to provide a
> > real default-mysqlclient-dev metapackage, which other packages can
> > build depend on, using versions if needed (just as default-jdk does).
>
> Yes.
>
> > Current mariadb-10.0 source package does not ship any
> > libmariadbclient18 nor libmariadbclient-dev packages at all, as
> > previously it was seen as against the policy (but mariadb-5.5 in
> > Debian did). I suggest we start producing them now again to make a
> > libmysqlclient.so(.18) available from mariadb-10.0.
> >
> > Having two libmysqlclient.so.18 files from two different packages is a
> > controversial topic. They are not identical so it is ugly to use the
> > same name. This is however a necessity dictated by the need to provide
> > a drop-in-replacement that can be used directly without going into
> > every single clienting program and editing the C headers and soname
> > calls.
>
> We discussed this in the release team and concluded that having two
> libmysqlclient.so.18 files in two packages is likely to run into problems
> later if/when they diverge, so there is no point delaying that pain.
> Especially as they are not identical even now.
Sorry, I'm not clear on the sense of your statement. By this, are you
agreeing to do it now, or saying that we shouldn't do it?
> I wonder if pkgconfig can be any help here? That involves a one-time change
> to client packages if they don't already use pkgconfig but doesn't have to
> be repeated if the default switches.
I experimented down another route. In my proposal, I keep the
libmysqlclient for MySQL only, and use libmariadbclient for the MariaDB
upstream. So:
PROPOSAL B
pkg:libmysqlclient18 ships libmysqlclient.so.18
pkg:libmysqlclient-dev ships libmysqlclient.so
(no change so far).
Then:
pkg:libmariadbclient18 is created to ship libmariadbclient.so.18
pkg:libmariadbclient-dev is created to ship libmariadbclient.so
These are new additions to src:mariadb-10.0. We have to patch a little
to switch from MariaDB from building libmysqlclient to use
libmariadbclient instead.
pkg:libmariadbclient-dev must conflict with pkg:libmysqlclient-dev
because they ship the same header files, but this affects builds only,
and not (normal) runtime.
Then:
pkg:libmariadbclient-dev-compat is created to ship a symlink:
libmysqlclient.so -> libmariadbclient.so. This must conflict with
pkg:libmysqlclient-dev, but again we're affecting builds only, and not
normal runtime.
pkg:default-libmysqlclient-dev is created to depend on
pkg:libmariadbclient-dev-compat.
What this gets us:
1) Maintainers can build against whichever one they prefer, and/or the
release team is in a position to be able to mandate a default as
required.
2) Users can build against either, and continue to use either. There is
no system wide choice being forced here.
3) No confusion between MySQL and MariaDB. "libmysqlclient.so.18" is
always MySQL and "libmariadbclient.so.18" is always MariaDB.
4) Maintainers need only change their build dependencies. Upstreams
that try to link using "-lmysqlclient" will continue to work.
END OF PROPOSAL
I tested this and it appears to work.
https://git.launchpad.net/~racb/ubuntu/+source/mariadb-10.0/log/ is my
MariaDB test modification (PoC with amd64 hardcoded). I created a
fake "equivs" libmysqlclient-dev that depends only on
libmariadbclient-dev-compat, and dropped the necessary conflicts, for
testing purposes. cacti-spine (a simple consumer of libmysqlclient) then
successfully linked against libmariadbclient.so.18 and depended on
pkg:libmariadbclient18 with no further modification.
If we want to test more packages, it's sufficient to just rebuild them
with my test build dependencies available.
Some commentary on my justifications above:
1) I believe this is the core of what the release team requested in
terms of MySQL and MariaDB. I appreciate of course that whatever hackery
we do to make this happen is something the release team should weigh in
on also.
3) I really don't want to go down the route of "libmysqlclient.so.18"
actually being MariaDB. It may be ABI-compatible now, but what about the
future? MySQL 5.7 already bumps to libmysqlclient.so.20, for example. If
and until MariaDB ships an ABI-compatible libmysqlclient.so.20, are we
going to ship both, one from each upstream? What if MariaDB's one turns
out not to be ABI compatible? I think down this path lies madness.
sonames give us a method to avoid this conflict by using different
names. We should use this if we can.
Feedback on this approach appreciated.
Robie
Reply to: