[debian-mysql] [MBF] mysql meta-packages

[Andreas Beckmann]

On 2016-12-18 12:23, Robie Basak wrote:
> On Sat, Dec 17, 2016 at 10:46:58PM +0100, Andreas Beckmann wrote:
>> Therefore I would suggest the following:
>>
>> Let's build a transitional mysql-server package from src:mysql-defaults
>> and have that depend on default-mysql-server. Version would be something
>> along 5.7.16+1.0.2 to take over the package from src:mysql-5.7
>> Temporarily stop building mysql-server from src:mysql-5.7 until the
>> freeze is over. After the freeze and after mysql-5.7 had a new upstream
>> release, build the package again from src:mysql-5.7.
> 
> We're still maintaining mysql-5.7 in sid, so I'm not particularly keen
> on this.

I understand and this doesn't mean to put mysql-5.7 on hold ... just
temporarily take away its mysql-server package.

> What happens if mysql-5.7 has a new upstream release before the freeze
> is over? I recall enquiries in the past asking for upstream security
> update releases soon after they appear. Would we be blocked from being
> able to upload these?

No problem, just don't enable building mysql-server, yet :-)
(if you want a mysql-server pointing to mysql-5.x instead of
default-mysql-server, upload it to experimental).

> We also have the same issue as in the other thread that mariadb-server
> doesn't behave exactly the same as mysql-server. Additionally,
> automatically transitioning users results in DB changes that cannot be
> reversed (ie. the user cannot switch back to MySQL again without manual
> intervention and ideally backups).

Oh yes ...

> So I think my two objections are:
> 
> 1) We have not decided to automatically switch users' data (effectively)
> irreversably from MySQL to MariaDB on upgrade. This should have been
> discussed at the time of making the decision to drop MySQL, but since
> the release team treated that as a fait accompli by filing bug 837615,
> that discussion never happened. Note that I'm saying that we have not
> decided to, not that we have decided not to. We just haven't had a
> discussion or made any decision.

That is a valid concern. Something I don't have to care for when doing
piuparts tests for this upgrade path ... there is no valuable user data
in my case.

My primary concern is to have a jessie->stretch system *silently* still
running mysql-server-5.5, but without security support.
"Silently" as in the upgrade succeeded and therefore the admin didn't
notice the he needs to do something manually.

> 2) We're still maintaining MySQL packaging; it doesn't seem reasonable
> to halt progress or impede that because of the release team's desires
> around stretch. Perhaps Debian's policies do allow this; in that case
> I'd be happy to be corrected by being pointed to documented policies in
> this area.

The general rule for the freeze is "don't do disruptive changes in sid",
s.t. fixes can usually be routed via sid instead of tpu.
(messing too much with sid will prolongate the freeze ... if you want to
break something - break experimental)


Andreas