Kevin Fenzi <kevin@xxxxxxxxx> 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 packages. regards, tom lane -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
