"J. Lewis Muir" <jlmuir%imca-cat.org@localhost> writes:
> What does changing the default implementation mean? My first impression
> is that it doesn't sound like a good idea to me. If I want a MySQL
> client or server, I would install the databases/mysql-client or
> databases/mysql-server package, respectively. (I understand that
> those packages don't currently exist, but I'm just saying what I
> would naturally do.) I would not expect that doing that would
> actually install a MariaDB client or server. If I want a MariaDB
> client or server, I would install the databases/mariadb-client or
> databases/mariadb-server package, respectively. (I understand that
> those packages don't currently exist, but I'm just saying what I would
> naturally do.) It's true that MariaDB started out with the intention of
> being a drop-in replacement for MySQL, but they have many implementation
> differences now, and even if they didn't, they're still different
> projects, so that would feel confusing to me to get MariaDB if I asked
> for MySQL.
I see your point, but in the world of messy forks, "this package depends
on mysql" means "this package needs an implementation of the API/ABI
typically provided by mysql", and as the things named mysql have
increasing license trouble and fall out of favor with packages that
depend on this API/ABI, it's going to make sense to use an alternative
implementation.
There are differences, but they feel along the lines of the kinds of
differences from one version of the same name to the next, made for the
same sort of reasons.
As before, if you want a specific implementation, you can install it
before you build other things. All we're talking about is which of
mysql{56,57,80} or mariadb{104,105} a package that "uses mysql" will
pull in.
We don't have a meta-package for mysql (or postgresql) that depends on
some version. It's the same default version for depending packages
scheme (except that there is no reason anybody wants to use a fork
instead).
One could instead rename mysql.buildlink3.mk to
mysql-like-apiabi.buildlink3.mk and then change all the packages to use
that instead and then make the change. But that's just added churn.
Attachment:
signature.asc
Description: PGP signature