Should MariaDB touch my.cnf in %post?

"Jóhann B. Guðmundsson" johannbg at gmail.com
Fri Feb 15 14:31:48 UTC 2013


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



More information about the devel mailing list