On 2016-01-30 at 08:49, Clint Byrum wrote: > Excerpts from The Wanderer's message of 2016-01-30 04:28:42 -0800: > >> On 2016-01-30 at 04:51, Paul Gevers wrote: >>> Actually, I don't think that is in scope of dbconfig-common. I >>> would rather expect that MariaDB would provide that >>> functionality. It is required for more packages and situations >>> than just those supported by dbconfig-common. >> >> Are there even cases where this is necessary? >> >> Within the last year, I encountered an unacceptable - but >> intentional - change in the MySQL client interface, so I removed >> the MySQL packages and installed the MariaDB ones. > > Which client interface would that be? libmysqlclient18 is still > provided by mysql, even if you install MariaDB. The one invoked with the command 'mysql'. The underlying library is still the same (though as far as I can see, the dependency chain from mariadb-client-core-10.0 to libmysqlclient18 only exists because libdbd-mysql-perl depends on the latter, so I'm not convinced that ), but the client itself behaves differently. The specific UI change which drove me away from "pure" MySQL was the change in line-editing library, away from readline, so that my habitual "jump around the line while editing the query" practices would no longer function - and, as far as I recall, there was no suitable replacement. I dug around for a while looking for a way to turn the readline behaviors back on, started digging into the process of building my own packages which revert to the old behavior, then discovered that MariaDB had not followed that change and decided to just migrate instead. >> My existing database was picked up and used without issues; the >> transition was, on that level, pretty much seamless as far as I >> recall. I might have needed to re-apply some configuration tweaks >> in different config files, but nothing more than that. > > This is a one-way trip as of MariaDB 10. MariaDB 5.5 was compatible > with MySQL 5.5 and allowed using the same on-disk files. But MySQL > may not know how to read all of the files produced by MariaDB 10+. So > I would not count on this working again in the future. They're truly > forks, and you will need to backup/restore to make this work. This is valuable to know for future reference, though I'm not sure I'm ever likely to need or want to migrate in that direction between the two; I was only still on MySQL rather than MariaDB out of inertia. Since the topic at hand was specifically migrating from MySQL to MariaDB, however, rather than bidirectional migration between the two, my question stands: are there cases where migration from MySQL to MariaDB needs to be done explicitly per-database? >> This seems to imply that either migration is not required, or >> MariaDB already performs the needed migration transparently. (Or >> else that I'm forgetting some part of the transition process, which >> is not impossible.) >> >> I can imagine that there could be cases where migration would be >> required, but I'm not aware of any, and it didn't even occur to me >> to expect that I might need to do any in my own case. I expected >> that the two would be seamlessly compatible on the database level, >> and that expectation seems to have been borne out. > > Yeah, that would be nice, but the reality is, code is only flowing > _away_ from MySQL at this point. MariaDB's changes don't go back > into MySQL. So the forks will just get further and further apart. That's more or less what I'd expect. It still seems possible that the "downstream" fork would retain input compatibility with the "upstream" parent, but certainly that's not guaranteed. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw
Attachment:
signature.asc
Description: OpenPGP digital signature