[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: openssl 1.1 fallout with mmysql, mysql succession planning?
* On 2020-01-20 at 17:38 GMT, Greg Troxel wrote:
> Jonathan Perkin <jperkin%joyent.com@localhost> writes:
> >> Do you mean, "other than mysql-5.5 which is EOL and for which there is
> >> no reason to use, only a few things broke, and they are all unmaintained
> >> and deletion candidates"?
> >> I am just trying to understand whether other than fixing the default,
> >> there is a tiny maybe-problem or something larger. It does seem that
> >> mysql-using packages in pkgsrc are now broken, which isn't ok.
> > Yeh, I forgot that pkgsrc still defaulted to 5.5, as that's not
> > something we (Joyent) have done for at least 5 years.
> I actually looked at the code and the default for mysql has been 57
> since some time in 2018.
Fair enough ;)
> >> > The complicated part is bringing over the changes from our pbulkmulti
> >> > branch so that users aren't forced into a single mysqlclient
> >> > implementation.
> >> I don't follow this. Right now pkgsrc users have to choose between
> >> mysql 5.5 5.6 or 5.7, and pretty clearly ought to choose 5.7 (from among
> >> those). Extending that set to add mariadb and percona seems like a good
> >> step forward. I can see the point that we would like bulk builds for
> >> multiple choices, but I don't see why that should block progress. Is
> >> that right, or am I missing something?
> > Part of the pbulkmulti code is an overhaul of mk/mysql.buildlink3.mk
> > to support alternate versions.
> So it works like postgresql, where multiple packages can be built
> against different versions but only one installed, or like python, or ?
> That sounds great, but I don't understand why not having that is a
> barrier to having more recent mariadb and percona in pkgsrc. I would
> think that someone would still have to choose a single systemwide
> version and then things would work or not. But that's what we have now,
> with fewer choices.
All I'm saying is that I don't have time to verify that my extensive
changes to mysql.buildlink3.mk are suitable for upstreaming yet and
can handle existing installations, and adding percona to the existing
mysql.buildlink3.mk would be brand new work I also don't have time for
(and would be a waste of that time given it would be overwritten
If someone else wants to do this work, awesome!
Jonathan Perkin - Joyent, Inc. - www.joyent.com
Main Index |
Thread Index |