Kevin Fenzi <kevin(a)scrye.com> writes:
I think I am with Remi on the above... shipping both for 1 release
would be potentially helpful in seeing issues, we can ask people to
migrate at that time and file bugs, if the bugs are stoppers they can
go back to mysql until fixed. I guess it depends on the maintainer(s)
involved if they feel this would be worthwhile.
There will be very substantial costs to either of the schemes that allow
mysql and mariadb to be installed in parallel. I'm pretty disinclined
to expend the packaging effort, or the user-education effort, if the
road map is that we're expecting to drop mysql altogether soon.
I'm OK with a ship-both-for-awhile plan as long as it's done by making
the packages simply Conflict:. Otherwise I think we'll be doing too
much throwaway work.
Personally, though, I lean to the just-do-it approach. Remember that
mariadb is in the end a fork of mysql. It seems unlikely to me that
there are bugs in it that are (a) not in mysql and (b) so catastrophic
as to justify the work of dual-packaging, even in the stripped down
form of just-make-them-conflict. So I'd rather just make the switch
(early in a devel cycle) and fix any bugs we run into.
As an example of the sort of work I'd rather not do, if we want to have
two packages then it'll be necessary to change BuildRequires in other
packages if we want to build/test them against mariadb. If we go
straight for the replacement approach, then we can say mariadb-devel
Provides: mysql-devel, and no source changes are needed in other
regards, tom lane