On 02/15/2013 01:50 PM, Honza Horak wrote:
On 02/15/2013 12:39 PM, "Jóhann B. Guðmundsson" wrote:
On 02/15/2013 11:07 AM, Honza Horak wrote:
<snip>
If mysql on the other hand is banned in the distribution then arguably
it makes sense to migrate those instances to the latest release of
mariadb instead thou I personally would not recommended it then either
but rather prefer it would be left alone then replaced by admin himself
after upgrade.
This will be indeed possible. If admin reads the release notes before
upgrading to F19 (which I suppose if they mind their data), he will be
aware of the change and will be able to disable mariadb packages for
the time of upgrade in order to not replace mysql. Then, anytime
later, he will be able to do the manual replacement.
That's wrong from my point of view and the opposite would be correct
behavior as in he would have to enable the mariadb packages to have them
replaced and by doing so he would at same time acknowledging that he was
aware of the changes. ( opposed to them surprising him later )
<snip>
In case it would be discussed, compatible, documented, noted in the
release notes and we have a good reason to do so -- then why not?
Different product different characteristics
I still see the differences between MariaDB and MySQL to be very little.
Difference never the less and difference in behavior ( which mariadbs
own benchmarking on their website proof ) which means every server tweak
that has been done for the mysql host has to be redone to take whatever
changes and features mariadb introduces.
If you install mate or cinnamon or unity for that matter would you
expect to be migrated and running Gnome 3.x after upgrade or would you
expect to be continuing to use and run what got forked or based of it.
This is already too extreme, we cannot compare Gnome forks and MySQL
forks. It's really a different scenario.
Same fundamental rules apply as I see it just different ( fork )
components.
So what about upstart->systemd or Gnome2->Gnome3 switches? These also
took place without users interaction and it was not without problems.
OK, they aren't forks, just new features. Why not take MariaDB just as
a new feature?
upstart was never properly integrated into the distribution so it's more
accurate to talk about sys V --> Systemd and my advice to any
distribution that thinks of making that switch to do so within one
release cycle and arguably systemd should never have had that backward
compatibility ( to that certain extent it has ) to sys V implemented.
Doing so has caused users to expect sysv/upstart like behavior of the
init systemd as opposed to approach and embrace it as new technology.
That said neither systemd nor Gnome 3 are forks however mariadb is so it
will ( as is the nature of all forks ) grow further away from it's
origin in time ( how fast that happens depends on it's maintainers ),
thus it should be treated as fork and a completely separated database
product that is *based* on mysql and packaged as such
Running both packages on the same server is not currently available,
because they conflict. If somebody does it in any way, which means to
separate files, sockets, ... then he should be able to separate config
files as well.
Is that not an clear indicator that the replacement should not take
place on upgrade but rather be left up to the administrator to do
manually ( at least while we still ship mysql ) and we have mysql and
mariadb conflict with each other on packaging level?
Well, in case we wouldn't obsolete mysql -- then either we could do it
in F20 and have the same problem a few months later
Sorry not following as long as someone is willing to maintain mysql in
the distribution we should not be dealing with any kind of potential
replacement migration.
or don't do it at all and then we would have troubles with CVE and
unfriendly upstream forever.
Still not following I would assume the more these two components grow
apart the more CVE troubles we have and which unfriendly upstream mysql
or mariadb one?
JBG
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
