Re: final decision about MySQL r-deps needed / cleaning up the MySQL mess

[Rene Engelhard]

Hi,

On Wed, Oct 19, 2016 at 08:26:22AM +1100, Dmitry Smirnov wrote:
> On Monday, 17 October 2016 9:01:24 PM AEDT Rene Engelhard wrote:
> > This means I'll orphan mysql-connector-c++ (well, remove myself from
> > Uploaders:, which makes it having no Uploader at all). Dmitry, if you
> > want/need it for mysql-connector-c++ feel free to add yourself and upload
> > 1.1.7 to whatever you want and it actually works.
> 
> (Eventually) I'll see what I can do but at the moment I have no capacity to 
> take care of mysql-connector-c++... Is there a public repository for its 
> packaging anywhere?

No, there's something at pkg-mysql but it's outdated. What is in 
sid/experimental
is what is current.

Regards,

Rene

Re: final decision about MySQL r-deps needed / cleaning up the MySQL mess

[Rene Engelhard]

Hi,

On Wed, Oct 19, 2016 at 08:20:25AM +1100, Dmitry Smirnov wrote:
> On Monday, 17 October 2016 3:33:29 PM AEDT Rene Engelhard wrote:
> >  - mysql-connector-c++s upstream is Oracle, so they obviously do not care
> >about MariaDB and (can) just require MySQL
> >  - mysql-workbench (also Oracle I think) in newer versions apparently needs
> > mysql-connector-c++ >= 1.1.7
> >  - mysql-connector-c++ starting from 1.1.5 (IIRC) needs MySQL >= 5.6 to
> > build (and doesn't build with MariaDB) and mysql-connector-c++ 1.1.7 needs
> > even MySQL >= 5.7
> 
> Sadly it is true that Oracle couldn't care less about mysql-workbench 
> compatibility with anything but MySQL 5.7... New versions of mysql-workbench 

I am not surprised.

> FTBFS with mysql-5.6 and with mariadb. mysql-workbench is stuck at v6.3.4 
> because upstream refuses to recognise/resolve FTBFS in newer versions that 
> upstream build against MySQL 5.7.

Ah, that might explain why you didn't even approach me that you need something
newer than 1.1.3 :)

> >(Interestingly, the mysql-workbench "maintainer" didn't do *any* action
> > or offer to help to fix https://bugs.debian.org/836731, which is why sid
> > is stuck with 1.1.3)
> 
>  * mysql-workbench maintainer is not even mentioned in #836731 let alone he 
> is not a maintainer of "mysql-connector-c++"...

Yeah, but as said I wondered why you didn't even ask for 1.1.7 going out
of experimental and deducted inactivity...

>  * mysql-workbench maintainer have no shortage of excuses for his inactivity: 
> among other issues that affect his performance there are new job, illness 
> (from which he did not recover yet) and sudden death of a family member in an 
> accident...

Ugh.

Regards,

Rene

Re: final decision about MySQL r-deps needed / cleaning up the MySQL mess

[Dmitry Smirnov]

On Monday, 17 October 2016 3:33:29 PM AEDT Rene Engelhard wrote:
>  - mysql-connector-c++s upstream is Oracle, so they obviously do not care
>about MariaDB and (can) just require MySQL
>  - mysql-workbench (also Oracle I think) in newer versions apparently needs
> mysql-connector-c++ >= 1.1.7
>  - mysql-connector-c++ starting from 1.1.5 (IIRC) needs MySQL >= 5.6 to
> build (and doesn't build with MariaDB) and mysql-connector-c++ 1.1.7 needs
> even MySQL >= 5.7

Sadly it is true that Oracle couldn't care less about mysql-workbench 
compatibility with anything but MySQL 5.7... New versions of mysql-workbench 
FTBFS with mysql-5.6 and with mariadb. mysql-workbench is stuck at v6.3.4 
because upstream refuses to recognise/resolve FTBFS in newer versions that 
upstream build against MySQL 5.7.


>(Interestingly, the mysql-workbench "maintainer" didn't do *any* action
> or offer to help to fix https://bugs.debian.org/836731, which is why sid
> is stuck with 1.1.3)

 * mysql-workbench maintainer is not even mentioned in #836731 let alone he 
is not a maintainer of "mysql-connector-c++"...

 * #836731 was silently merged with related #835185 at which mysql-workbench 
maintainer looked but unfortunately couldn't find anything with his limited 
knowledge of C++. He then tagged bug #835185 "help".

 * mysql-workbench maintainer have no shortage of excuses for his inactivity: 
among other issues that affect his performance there are new job, illness 
(from which he did not recover yet) and sudden death of a family member in an 
accident...

 * mysql-workbench maintainer is unable to deal with complex C++ issues on 
his own and upstream is not helpful (or at least ignores comments about 
compatibility raised in their bug tracker). mysql-workbench maintainer wishes 
he could be more useful but there is only little he can do... :(

-- 
Best wishes,
 Dmitry Smirnov.

---

Criticism may not be agreeable, but it is necessary. It fulfils the same
function as pain in the human body. It calls attention to an unhealthy
state of things.
-- Winston Churchill


signature.asc
Description: This is a digitally signed message part.

Re: final decision about MySQL r-deps needed / cleaning up the MySQL mess

[Dmitry Smirnov]

Hi Rene,

On Monday, 17 October 2016 9:01:24 PM AEDT Rene Engelhard wrote:
> This means I'll orphan mysql-connector-c++ (well, remove myself from
> Uploaders:, which makes it having no Uploader at all). Dmitry, if you
> want/need it for mysql-connector-c++ feel free to add yourself and upload
> 1.1.7 to whatever you want and it actually works.

(Eventually) I'll see what I can do but at the moment I have no capacity to 
take care of mysql-connector-c++... Is there a public repository for its 
packaging anywhere?

Newer versions of MySQL Workbench FTBFS with mysql-connector-c++ in 
"experimental" but that's upstream problem which I'm unable to fix...

Thanks for looking after mysql-connector-c++ all those years.

-- 
All the best,
 Dmitry Smirnov.

---

Good luck happens when preparedness meets opportunity.


signature.asc
Description: This is a digitally signed message part.

Re: [debian-mysql] final decision about MySQL r-deps needed / cleaning up the MySQL mess

[Rene Engelhard]

Hi,

On Tue, Oct 18, 2016 at 01:17:27PM +0300, Otto Kekäläinen wrote:
> 2016-10-18 11:38 GMT+03:00 Rene Engelhard :
> > Simple: Because LO uses the C++ bindings and not the C bindings? If you
> > mean why I don't build mysql-connector-c++ against mariadb, see my initial
> > mail. Newer versions of it do not build with it. (the version in sid is
> > ooold.)
> 
> MariaDB Connector C is for C++ also. I am not an expert on the topic,
> but I assume you could just try it directly and see if it builds or if
> it complains about some missinng API call or not?

Obviously not, mysql-connector-c++ is a C++ API with classes and namespaces
etc (and Lo uses sql:: all over the place). You maybe can explain
how something with a C API can be a standalone replacement? One doesn't even
need to try to know this wouldn't work :)

Regards,

Rene

Re: [debian-mysql] final decision about MySQL r-deps needed / cleaning up the MySQL mess

[Otto Kekäläinen]

2016-10-18 11:38 GMT+03:00 Rene Engelhard :
> Simple: Because LO uses the C++ bindings and not the C bindings? If you
> mean why I don't build mysql-connector-c++ against mariadb, see my initial
> mail. Newer versions of it do not build with it. (the version in sid is
> ooold.)

MariaDB Connector C is for C++ also. I am not an expert on the topic,
but I assume you could just try it directly and see if it builds or if
it complains about some missinng API call or not?

See
* https://mariadb.com/kb/en/mariadb/mariadb-connector-c/
* https://packages.debian.org/sid/libmariadb-dev
* https://packages.debian.org/sid/libmariadb-dev-compat
* https://packages.debian.org/stretch/libmariadbclient-dev
* https://packages.debian.org/stretch/libmariadbclient-dev-compat

Re: [debian-mysql] final decision about MySQL r-deps needed / cleaning up the MySQL mess

[Otto Kekäläinen]

Hello!

2016-10-17 22:01 GMT+03:00 Rene Engelhard :
> This means I'll orphan mysql-connector-c++ (well, remove myself from 
> Uploaders:,
> which makes it having no Uploader at all). Dmitry, if you want/need it
> for mysql-connector-c++ feel free to add yourself and upload 1.1.7 to whatever
> you want and it actually works.
>
> For LO, I disabled libreoffice-mysql-connector.

I didn't find a package called mysql-connector-c++, is it already removed?

I only found this:
https://packages.debian.org/stretch/libreoffice-mysql-connector

The package seems to contain mysqlc.uno.so - this is unique to
LibreOffice? I didn't quite understand why you cannot build against
libariadbclient-dev or using the mariadb-connector-c?

- Otto

Re: [debian-mysql] final decision about MySQL r-deps needed / cleaning up the MySQL mess

[Rene Engelhard]

Hi,

On Tue, Oct 18, 2016 at 11:28:32AM +0300, Otto Kekäläinen wrote:
> 2016-10-17 22:01 GMT+03:00 Rene Engelhard :
> > This means I'll orphan mysql-connector-c++ (well, remove myself from 
> > Uploaders:,
> > which makes it having no Uploader at all). Dmitry, if you want/need it
> > for mysql-connector-c++ feel free to add yourself and upload 1.1.7 to 
> > whatever
> > you want and it actually works.
> >
> > For LO, I disabled libreoffice-mysql-connector.
> 
> I didn't find a package called mysql-connector-c++, is it already removed?

The source package is mysql-connector-c++.
https://packages.qa.debian.org/m/mysql-connector-c%2B%2B.html

> I only found this:
> https://packages.debian.org/stretch/libreoffice-mysql-connector
> 
> The package seems to contain mysqlc.uno.so - this is unique to
> LibreOffice?

Yees, that's the LO component. And you see that it depends on libmysqlcppconn7v5

> I didn't quite understand why you cannot build against
> libariadbclient-dev or using the mariadb-connector-c?

Simple: Because LO uses the C++ bindings and not the C bindings? If you
mean why I don't build mysql-connector-c++ against mariadb, see my initial
mail. Newer versions of it do not build with it. (the version in sid is
ooold.)

Regards,

Rene

Re: final decision about MySQL r-deps needed / cleaning up the MySQL mess

[Rene Engelhard]

Hi,

On Mon, Oct 17, 2016 at 03:33:29PM +0200, Rene Engelhard wrote:
> The release and security teams have decided that MySQL will live only in
> unstable for stretch due to the perceived complications with tracking
> security patches in MySQL.
> --- snip ---
> 
> which then also implies mysql-* will be removed which  then also implies
> thet everything needs to transition away from it or it (will be removed).
> 
> This was also said in a discussion on #debian-mysql. Without any 
> acknowlegement
> that there should have been more direct communication of what people should 
> do.
> 
> So what should a maintainer do?
> 
> Remove MySQL dependencies and replace it with MariaDB or it won't be in 
> stretch?
> What happens for stuff requring MySQL?

FTR:

According to #debian-release, yes:

15:43 < jcristau> this doesn't sound like it needs us involved
15:46 < _rene_> well, if there's a "RT decision" to get rid of MySQL 
alltogether...
15:47 < jmw> the release team is desperately trying *not* to be involved...
15:47 < _rene_> so there is and people should dump MySQL-only-r-deps?
15:47 < _rene_> jmw: well, there is claims that you were involved in the way 
that you said wou want to get rid of it and remove mysql-* for 
stretch
15:48 < _rene_> in any case maintainers need to know what they are supposed to 
do
15:48 < jmw> we want a security team-supported variant in stretch
15:48 < jmw> that's the big deal at the moment
15:48 < _rene_> yes, and at some point in time one needs to decide what that 
invovoles wnd what to do with MySQL-related packages.
15:48 < jcristau> _rene_: yes, so mysql-only r-deps won't be in stretch

This means I'll orphan mysql-connector-c++ (well, remove myself from Uploaders:,
which makes it having no Uploader at all). Dmitry, if you want/need it
for mysql-connector-c++ feel free to add yourself and upload 1.1.7 to whatever
you want and it actually works.

For LO, I disabled libreoffice-mysql-connector.

Regards,
 
Rene

final decision about MySQL r-deps needed / cleaning up the MySQL mess

[Rene Engelhard]

Hi Release Team,

I am completely confused and puzzled about the currrent MySQL vs. MariaDB
situation.

There was
https://lists.debian.org/debian-devel-announce/2016/09/msg0.html

I brought this up in
http://lists.alioth.debian.org/pipermail/pkg-mysql-maint/2016-August/009346.html
and as told that I can continue (build-)depending on libmysqlclient from MySQL.

Especially given
 - mysql-connector-c++s upstream is Oracle, so they obviously do not care
   about MariaDB and (can) just require MySQL
 - mysql-workbench (also Oracle I think) in newer versions apparently needs
   mysql-connector-c++ >= 1.1.7
 - mysql-connector-c++ starting from 1.1.5 (IIRC) needs MySQL >= 5.6 to build
   (and doesn't build with MariaDB) and mysql-connector-c++ 1.1.7 needs even
   MySQL >= 5.7
 - both LO and MySQL Workbench crash with > 1.1.3 of mysql-connector-c++
   at least on i386
   (Interestingly, the mysql-workbench "maintainer" didn't do *any* action or
offer to help to fix https://bugs.debian.org/836731, which is why sid
is stuck with 1.1.3)

Now I saw this upload today:

Format: 1.8
Date: Wed, 05 Oct 2016 13:10:56 +0200
Source: mysql-5.7
[..]
Description:
 libmysqlclient-dev - MySQL database development files
 libmysqlclient20 - MySQL database client library
[...]
Closes: 837883
Changes:
 mysql-5.7 (5.7.15-1) unstable; urgency=medium
[...]

which obviously will cause in a (uncoordinated) transition.

While it could be be done, I saw
http://lists.alioth.debian.org/pipermail/pkg-mysql-maint/2016-October/009583.html,
 which says:

--- snip ---
The release and security teams have decided that MySQL will live only in
unstable for stretch due to the perceived complications with tracking
security patches in MySQL.
--- snip ---

which then also implies mysql-* will be removed which  then also implies
thet everything needs to transition away from it or it (will be removed).

This was also said in a discussion on #debian-mysql. Without any acknowlegement
that there should have been more direct communication of what people should do.

So what should a maintainer do?

Remove MySQL dependencies and replace it with MariaDB or it won't be in stretch?
What happens for stuff requring MySQL?

In this specific case, what should I do?

a) keep mysql-connector-c++ built against MySQL? That would mean keeping
   mysql-5.7 because of the libreoffice-mysql-connector -> libmysqlcppconnv5 ->
   libmysqlclient20 dependency chain.
   This would mean I could keep libreoffice-mysql-connector and at some time
   in the future mysql-workbench could use this, too
b) build mysql-connector-c++ 1.1.3 against MariaDB? Would work for 1.1.3 (and
   probably 1.1.4), but not for anything >= 1.1.5 as that one needs MySQL 5.6
   ot even 5.7 to build and subsequently don't build against MariaDB (see
   above).
   This would mean I could keep libreoffice-mysql-connector but would cause
   issues for proper packaging of mysql-workbench. But then again Dmitry
   can take it over?  
c) drop libreoffice-mysql-connector

 (thereoretically there's c0) meaning "use internal mysql-connector-c++ 1.1.4,
 which we then could build against MariaDB, but that would introduce usage
 of a internal code copy, and I've no idea whether that 1.1.4 build will also 
 be affected by https://bugs.debian.org/836731. So  the "safe" solution would
 be c))

Regards,

Rene