|
Home > Archive > Debian Developers > March 2005 > eleventh-hour transition for mysql-using packages related to apache
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
eleventh-hour transition for mysql-using packages related to apache
|
|
| Steve Langasek 2005-01-28, 7:53 am |
| Previously, a number of packages have had to continue to link against
libmysqlclient10 in spite of the availability of libmysqlclient12 libraries
from upstream's mysql 4.0 release. Some of these have been due to the lack
of a clear license exemption allowing libmyslqclient12 to be linked from
GPL-incompatible programs; others have been held back to avoid segfaults
caused by loading both libmysqlclient10 and libmysqlclient12 in the same
address space.
Over the past six months, the situation has changed significantly. The
mysql maintainer, mysql upstream, and others have admirably worked through
the license issues to get a license exception that meets the needs of the
software that Debian distributes. You can find the current version of this
license exception at [1]. At the same time, compatibility between the old
client libs and the current server (including the version that we will ship
with sarge) has waned, to the point that no libmysqlclient10 clients will
work with the default configuration of mysql 4.1, and some won't work with
any mysql 4.x server at all [2].
As a result, in spite of the timing wrt the release, I'm proposing a
transition to libmysqlclient12 for a number of packages for sarge. The
packages listed below are those packages currently in sarge which either are
broken with mysql 4.x, or have the possibility of conflicting with one of the
packages that do (mostly by being loaded by a webserver such as apache or
apache2, or being mysql bindings for a language that also has ODBC bindings).
aspseek-libmysqldb
catalog
caudium-php4
freeradius-mysql
gda-mysql
gda2-mysql
libapache-mod-acct-mysql
libapache-mod-auth-mysql
libapache-mod-mp3
libapache2-mod-auth-mysql
libdbd-mysql
libdbd-mysql-perl
libgnademysql1
libmyodbc
libmysql-ruby1.6
libmysql-ruby1.8
libsqlxx2.3c102
mysqltcl
php3-mysql
php4-mysql
python2.2-mysqldb
python2.3-mysqldb
It would also probably be a good idea to transition these packages at the
same time:
dovecot-common
exim4-daemon-heavy
libnss-mysql
libnss-mysql-bg
libpam-mysql
libsasl2-modules-sql
I have Cc:ed the maintainers of these packages. If anyone knows of other
packages linked to libmysqlclient10 that will be affected by this
transition, please let us know.
While introducing versioned symbols into the mysqlclient libraries could
have a longer-term benefit in eliminating the kind of segfaults motivating
this all-at-once transition, in the present case there are other factors:
- since libmysqlclient10 didn't use symbol versioning in woody, users would
still get segfaults from partial upgrades
- getting benefits from symbol versioning requires rebuilding all packages
depending on the library *anyway*, so we might as well upgrade to the new
version of the lib in the process.
I think it would be beneficial if libmysqlclient12 used symbol versioning
for sarge, but I don't think that we should wait for that to happen before
fixing the present issues.
The current plan for this transition is as follows:
- I will transition libmyodbc and php4 to libmysqlclient12 at the end of
this weekend. Other maintainers are encouraged to upload around the same
time. Maintainers who will not be around this week, and would like their
packages to be NMUed, can email me privately.
- On Wednesday, Feb 2, I will file grave bugs on any remaining packages from
the first list above that have not been relinked against libmysqlclient12,
because they will now certainly cause segfaults in certain configurations.
The packages in the second group will not be targetted, because NSS and
PAM modules may cause some segfaults regardless of which library they link
against, so the fact that they do not already have RC bugs against them
means that this problem is probably quite rare.
- On Saturday, Feb 5, I will begin NMUing any packages from the first list
that have still not been fixed. Since there are only 17 source packages
total, I expect to be done by the end of the weekend.
If you object to this plan, please speak up now.
Cheers,
--
Steve Langasek
postmodern programmer
[1] http://www.mysql.com/company/legal/...-exception.html
[2] http://bugs.debian.org/274879
| |
| Andreas Metzler 2005-01-28, 8:47 pm |
| On Fri, Jan 28, 2005 at 05:03:26AM -0800, Steve Langasek wrote:
[...]
> Over the past six months, the situation has changed significantly. The
> mysql maintainer, mysql upstream, and others have admirably worked through
> the license issues to get a license exception that meets the needs of the
> software that Debian distributes. You can find the current version of this
> license exception at [1].
At a short glance this still seems to be missing a OpenSSL exception.
- Has this been resolved?
[...]
> exim4-daemon-heavy
[...]
> libpam-mysql
[...]
These two would need to change at the same time, otherwise #235938
would reappear. (A symbol clash when using PAM authenticcation in exim
on a system using pam-mysql.)
[...]
> I think it would be beneficial if libmysqlclient12 used symbol versioning
> for sarge, but I don't think that we should wait for that to happen before
> fixing the present issues.
[...]
Upstream has denied adding versioned symbols once
(http://bugs.debian.org/236288) they'd need to be convinced.
cu andreas
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| sean finney 2005-01-28, 8:47 pm |
| On Fri, Jan 28, 2005 at 04:36:05PM +0100, Andreas Metzler wrote:
> On Fri, Jan 28, 2005 at 05:03:26AM -0800, Steve Langasek wrote:
> [...]
>
> At a short glance this still seems to be missing a OpenSSL exception.
> - Has this been resolved?
no, afaik the openssl-related code in debian mysql-foo is disabled[1].
not that i wouldn't mind having it back...
sean
[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=291945
--
| |
| Andreas Metzler 2005-01-28, 8:47 pm |
| On 2005-01-28 sean finney <seanius@debian.org> wrote:
> On Fri, Jan 28, 2005 at 04:36:05PM +0100, Andreas Metzler wrote:
[vbcol=seagreen]
[vbcol=seagreen]
> no, afaik the openssl-related code in debian mysql-foo is disabled[1].
[...]
This seems to break the whole plan. A nontrivial number of packages
need to link against libmysqlclient* _and_ libssl. If libmysql12's
license does not allow that, we are screwed.
ametzler@downhill:~$ grep-available -FDepends libmysqlclient10 | grep-dctrl -FDepends -sPackage -n libssl
perdition-mysql
dovecot-common
caudium-php4
sqlrelay-mysql
motion
pure-ftpd-mysql
proftpd-mysql
gnugk
And these are just direct linkages against both libraries, there's
also a lot of bar depends on both libmysqlclient10 and libbar and
libbar itself links against libssl. - I never remember whether we
actually (have to) respect indirect linkage like that license-wise but
judging from cadaver I guess we do.
cu andreas
--
"See, I told you they'd listen to Reason," [SPOILER] Svfurlr fnlf,
fuhggvat qbja gur juveyvat tha.
Neal Stephenson in "Snow Crash"
http://downhill.aus.cc/
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Steve Langasek 2005-01-28, 8:47 pm |
| On Fri, Jan 28, 2005 at 08:17:18PM +0100, Andreas Metzler wrote:
> On 2005-01-28 sean finney <seanius@debian.org> wrote:
[vbcol=seagreen]
[vbcol=seagreen]
> [...]
> This seems to break the whole plan. A nontrivial number of packages
> need to link against libmysqlclient* _and_ libssl. If libmysql12's
> license does not allow that, we are screwed.
> ametzler@downhill:~$ grep-available -FDepends libmysqlclient10 | grep-dctrl -FDepends -sPackage -n libssl
> perdition-mysql
> dovecot-common
> caudium-php4
> sqlrelay-mysql
> motion
> pure-ftpd-mysql
> proftpd-mysql
> gnugk
Of these packages, the only one that was on the list of packages that need
to transition together is caudium-php4. The php4 source package is also due
for a reorg to enable ZTS, which will remove the need for statically
building the mysql extension into this package; if we need to make this
change at the same time as the mysql transition, then so be it.
The only other package in your list that was mentioned at all in my email
is dovecot-common, which is only loosely coupled with the others as a result
of libpam/nss-mysql and libsasl2-modules-sql.
> And these are just direct linkages against both libraries, there's
> also a lot of bar depends on both libmysqlclient10 and libbar and
> libbar itself links against libssl. - I never remember whether we
> actually (have to) respect indirect linkage like that license-wise but
> judging from cadaver I guess we do.
This affects the php packages, since all the SAPI alternatives that
php4-mysql can use currently link against libssl. I'll need to investigate
more to see if we can get away from this; even if it means dropping the PHP
OpenSSL extension, I think it's probably still a good trade.
It also seems to affect libapache2-mod-auth-mysql, since apache2 includes
https support by default. I don't see any way to fix this one.
I don't see any other packages in the list that are likely to have this
problem, although I haven't traced the dependencies to be sure.
That leaves us with several choices:
- ignore libapache2-mod-auth-mysql for the transition, and hope the actual
incidence of segfaults from intersecting libraries is low.
- push symbol versioning into libmysqlclient10 and libmysqlclient12, and
break up the transition
- cajole upstream into adding OpenSSL to the list of license exceptions
- ship sarge with a broken myodbc package
Of course, I would in any case delay the transition until we can decide on a
way forward from here.
Comments?
--
Steve Langasek
postmodern programmer
| |
| Andreas Metzler 2005-01-29, 7:48 am |
| On 2005-01-28 Steve Langasek <vorlon@debian.org> wrote:
[...]
> It would also probably be a good idea to transition these packages at the
> same time:
> dovecot-common
> exim4-daemon-heavy
> libnss-mysql
> libnss-mysql-bg
> libpam-mysql
> libsasl2-modules-sql
[...]
Hello,
These four packages also link against both libpam and libmysqlclient10
and might experience segfaults when accessing mysql over PAM with
libpam-mysql if libpam-mysql switched to libmysqlclient12:
linesrv-mysql, pure-ftpd-mysql, proftpd-mysql and courier-authmysql
I am saying /might/ as it is entirely possible that one or more of
these link against libpam without using it.
(The two mentioned ftp daemons probably cannot switch to -12, as they
link against libssl.)
cu andreas
PS: This is all about "would also probably be a good idea..." in
Steve's original mail, I have not said anything
substantial/useful/worthy to read about the rest of it. ;-)
--
"See, I told you they'd listen to Reason," [SPOILER] Svfurlr fnlf,
fuhggvat qbja gur juveyvat tha.
Neal Stephenson in "Snow Crash"
http://downhill.aus.cc/
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Francesco Paolo Lovergine 2005-01-31, 5:56 pm |
| On Sat, Jan 29, 2005 at 02:34:07PM +0100, Andreas Metzler wrote:
> Hello,
> These four packages also link against both libpam and libmysqlclient10
> and might experience segfaults when accessing mysql over PAM with
> libpam-mysql if libpam-mysql switched to libmysqlclient12:
>
> linesrv-mysql, pure-ftpd-mysql, proftpd-mysql and courier-authmysql
>
> I am saying /might/ as it is entirely possible that one or more of
> these link against libpam without using it.
>
> (The two mentioned ftp daemons probably cannot switch to -12, as they
> link against libssl.)
For what concern proftpd, it does not use libpam-mysql at all,
so I see no problem for that.
I can confirm for proftpd-mysql/libssl issue.
Me was one that asked mysql people to consider libssl for the new FLOSS,
without results. At least they included explicitly links to
opensource.org and FSF for licenses, else that FLOSS would be also more bad now.
Currently, I cannot move to libmysqlclient12. I would see if gnutls can
be used instead of libssl, but some modules are not supported upstream
in that way (e.g. mod_ldap). Grrrr.
--
Francesco P. Lovergine
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Andreas Metzler 2005-02-02, 5:56 pm |
| [Cc ing Frankie as the foo@p.d.o addresses appear to be non-functional]
On 2005-01-31 Francesco Paolo Lovergine <frankie@debian.org> wrote:
> On Sat, Jan 29, 2005 at 02:34:07PM +0100, Andreas Metzler wrote:
[vbcol=seagreen]
[vbcol=seagreen]
[vbcol=seagreen]
[vbcol=seagreen]
> For what concern proftpd, it does not use libpam-mysql at all,
> so I see no problem for that.
Hello,
Ehh. As maintainer of a PAM-using application you usually have no
control which PAM modules are used. You just ship the application with
a /etc/pam.d/foo using
@include common-<whatever>
and the *end-user* can (and probably will, if he installs stuff like
libpam-mysql) change these defaults to use modules of his choice.
cu andreas
--
"See, I told you they'd listen to Reason," [SPOILER] Svfurlr fnlf,
fuhggvat qbja gur juveyvat tha.
Neal Stephenson in "Snow Crash"
http://downhill.aus.cc/
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Francesco Paolo Lovergine 2005-02-02, 5:56 pm |
| On Wed, Feb 02, 2005 at 09:49:31PM +0100, Andreas Metzler wrote:
>
>
> Hello,
> Ehh. As maintainer of a PAM-using application you usually have no
> control which PAM modules are used. You just ship the application with
> a /etc/pam.d/foo using
>
> @include common-<whatever>
>
> and the *end-user* can (and probably will, if he installs stuff like
> libpam-mysql) change these defaults to use modules of his choice.
> cu andreas
That's clear. I did mean proftpd-mysql does not use PAM to authenticate
against mysql, it uses mysql API directly... Of course a PAM module
can be used by user, but that's not of interest for licensing
compatibility.
--
Francesco P. Lovergine
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Francesco P. Lovergine 2005-02-11, 7:59 am |
| FYI: new mysql FLOSS includes OpenSSL license, so many packages could
migrate to current libmysqlclient starting from no starting from now..
--
Francesco P. Lovergine
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| sean finney 2005-02-11, 7:59 am |
| On Fri, Feb 11, 2005 at 10:15:55AM +0100, Francesco P. Lovergine wrote:
> FYI: new mysql FLOSS includes OpenSSL license, so many packages could
> migrate to current libmysqlclient starting from no starting from now..
that's great to hear! i'm cc'ing the relevant wishlist bug i have open
against mysql-server. christian: any chance of getting an openssl enabled
version of the mysql-client and mysql-server packages?
sean
--
| |
| Theodore Ts'o 2005-03-02, 7:51 am |
| On Fri, Jan 28, 2005 at 05:03:26AM -0800, Steve Langasek wrote:
> As a result, in spite of the timing wrt the release, I'm proposing a
> transition to libmysqlclient12 for a number of packages for sarge. The
> packages listed below are those packages currently in sarge which either are
> broken with mysql 4.x, or have the possibility of conflicting with one of the
> packages that do (mostly by being loaded by a webserver such as apache or
> apache2, or being mysql bindings for a language that also has ODBC bindings).
Out of curiosity, where are we with this at this point? My system
(currently running unstable, but it from the your description it
sounds like it may be happening on sarge as well) has an
apache2/mysql/php4 combination which blows up the moment you try to
open a connection to a mysql database. That seems to be.... rather
unfortunate for those silly people like myself that are trying to
setup a LAMP stack.
What is the best thing to do at this point? Tell folks to use
MySQL 3.x instead?
- Ted
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Steve Langasek 2005-03-04, 2:52 am |
| On Thu, Mar 03, 2005 at 06:38:33AM +1100, Adam Conrad wrote:
> Theodore Ts'o said:
[vbcol=seagreen]
> Are you sure you're note experiencing the bugs listed in #295998 and
> #296694, which are fixed in 4.3.10-8 in unstable?... If not, then I guess
> the transition has started with some packages and not others, and we need
> to resolve that ASAP. It was stalled for a bit pending some license
> issues, but Steve and I got that resolved upstream recently.
> Steve, should we be going ahead with the push to make this transition
> occur as soon as we can, now that the license mess is sorted?
Yes, now that the license issue has been sorted out and we've finally gotten
the PHP4 ABI change/security fixes into testing, I think it's time at last
to get moving on the libmysqlclient transition.
The timing is rotten for me to do anything here until probably the middle of
next week; but if maintainers can use the weekend for uploading packages
built against libmysqlclient12, I'll follow through with the rest of the
original bug filing/NMUing plan on Wednesday. (My own maintainer uploads
will most likely have to wait until then as well.)
Please refer to <http://lists.debian.org/debian-deve...1/msg01757.html>
if you need a reminder of what needs to happen. The adjusted timeline will
be as follows:
- Maintainer uploads to transition to libmysqlclient12 will begin this
weekend. This will most likely not include myodbc, but may include php4
if I rope Adam into it.
- On Wednesday, Mar 9 I will file grave bus on any remaining packages from
the original list that have not been relinked against libmysqlclient12.
- On Saturday, Mar 12 I will begin NMUing any packages from that list which
have not been fixed.
Thanks,
--
Steve Langasek
postmodern programmer
|
|
|
|
|