[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: libmysqlclient12 to libmysqlclient14 transition



On Mon, Oct 17, 2005 at 09:51:46PM +0200, Christian Hammers wrote:

> In Debian Sarge we had libmysqlclient12 from MySQL 4.0.x as main mysql library
> in use. In Etch I already have MySQL 4.1 (libmysqlclient14) and MySQL 5.0
> (libmysqlclient15) which is still only release-candidate, so I'd like to drop
> support for the 4.0 branch completely.

> Note though, that libmysqlclient10-dev from mysql (3.23.x), maintained by
> Steve Langasek, which is also still present is left untouched because it was
> released under LGPL instead of "GPL+FLOSS Exceptions" and thus be preferred by
> some people. 

FWIW, I intend to drop libmysqlclient10 during the etch cycle; it was
packaged primarily because *PHP* needed it, but that license issue has been
resolved, so I don't really want to keep maintaining it in the long term.
I'd rather identify any remaining license exceptions that we might need
(which Adam Conrad said he was working on), and then bump everyone to 14.

> As we have recently introduced versioned symbols to libmysqlclient14 and -15
> the transition "should be easy"(tm) and done just by mass filing a bug report
> and maybe after 2 weeks NMU the leftover packages.

On Tue, Oct 18, 2005 at 10:18:50PM +0200, Christian Hammers wrote:

> On 2005-10-18 Nathanael Nerode wrote:
> > > Release Team, please comment :-)

> > Can you wait on this until the KDE/JACK transition goes through, new libpng
> > gets into etch, and new openssl does too?

> But I asked first back in july, JACK cheated the queue! :-)))

Well, yes, but JACK cheated the queue by virtue of the fact that the new
version was apparently uploaded before even the maintainer recognized that a
large transition was required. :/

libpng and openssl aren't really queue jumping, because these are both
"soft" transitions -- both the old and new versions of the library exist in
parallel, so we don't have to have everything ready to transition into
testing at once.  This is in contrast to the C++ ABI transition, which
*can't* be done in parallel with an old version and therefore requires all
related packages to be ready to go at once.

This is why the C++ ABI transition needs to be prioritized over everything
else in order to make it happen.  The libmysqlclient transition is also a
soft transition, so we shouldn't be encouraging people to re-upload packages
right now *just* for this transition; any communications about this need to
make it very clear that this is a change that should be made next time you
have a reason to upload, *not* a change that *warrants* an upload.

> Apropos, does the release team have a list of waiting transitions or should I
> just bounce my last mail every couple of weeks when I see that the list is
> getting quiet?

Other than the mess tied up with KDE, the only other one I know of currently
is that ocaml wants to bump upstream versions.

On Wed, Oct 19, 2005 at 08:54:27PM +0200, Andreas Barth wrote:
> * Andreas Metzler (ametzler@downhill.at.eu.org) [051019 18:58]:
> > On 2005-10-17 Christian Hammers <ch@debian.org> wrote:
> > > In Debian Sarge we had libmysqlclient12 from MySQL 4.0.x as main mysql library
> > > in use. 
> > [...]
> > > Maintainers:
> > >   Recompiling with build-deps set to libmysqlclient14-dev instead of
> > >   libmysqlclient12-dev should be enough.
> > [...]

> > How about

> > | Please transition to libmysqlclient14-dev *if* you make an upload
> > | anyway. But please do not make uploads just for this transition.
> with an additional ", at least not now (iow, you'll get an update as
> soon as this transition is called for)" this seems to be fine from a
> "flow to testing" point-of-view.

Yep, I think that captures it.

Cheers,
-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
vorlon@debian.org                                   http://www.debian.org/

Attachment: signature.asc
Description: Digital signature


Reply to: