"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