maria-developers team mailing list archive

[Reindl Harald <h.reindl@xxxxxxxxxxxxx>]

way easier - don't purge it at all - there is a reason why
the package manager on Redhat based systems *never* removes
subfolders below /var/lib

versioned datadirs are a hell

* it's the distributions responsiblity not allow *install*
  different mysql favours at the same time (conflicts in RPM)

* it's the admins responsibility not down- and side-grade
  without thinking and making backups

breaking upgrades because boder cases is a bad idea

we are working here with MariaDB 5.5.38 on datadirs originally
created with MySQL 3.x around 13 years ago on MacOSX and they
are just upgraded over years with "mysql_upgrade" and moved
between arcihtectures and operating systems

*only* if that would not be possible in a future version it
would need action and fixes - down and side-grades are always
critical and should always be only done once and in one
direction

Am 24.07.2014 14:23, schrieb Jean Weisbuch:
> I dont think that the option to have one datadir per major version (eg: /var/lib/mysql-5.6) is a good idea, it will
> add confusion and might break scripts or symlinks on major version upgrade for example while only one major version
> should exist at once on the system (at least if the current way of handling mysql versions is done on Debian).
> 
> As for the switching to a different datadir, it would also imply to use a different config directory as well such
> as /etc/mariadb as the datadir is actually set on /etc/mysql/my.cnf.
> 
> The whole debate depends on the possibility to install mariadb and mysql on the same system, if its not the path
> chosen, i would prefer to keep the /var/lib/mysql datadir as the default datadir and add checks on
> mysql/mariadb-server packages purge not to remove the datadir if any of the fork packages is still installed and
> throw a warning message about the possible incompatibility and upgrade methods on "migration".
> 
> Creating a script to simplify the migration for non-drop-in forks (eg: maria10 and mysql5.6) would also be a
> possibility, it would check if any of the tables on the server has a table engine that is not present on the other
> (eg: aria on mysql) or specific row/columns formats and would dump all tables and grants and import it on the new
> installation.
> 
> On 07/24/2014 02:04 PM, Otto Kekäläinen wrote:
>> Hello!
>>
>> Does the MariaDB project have any plans about switching the data dir
>> to /var/lib/mariadb in some release?
>>
>> In Debian there has been discussion about separating the
>> binary-incompatible MySQL forks into separate /var/lib/<fork> to ease
>> maintenance and secure data so that purging some packages will not
>> accidentally delete data that another package uses.
>>
>> The thread is named "Discussion on handling 5.6 related matters" and
>> available at http://lists.alioth.debian.org/pipermail/pkg-mysql-maint/2014-July/thread.html
>>
>> I'd appreciate any guidelines here on what the upstream plans are.
>>
>> The Debian MySQL/MariaDB packaging team willl have an IRC meeting
>> tomorrow at 16:00 UTC and I need to express my opinion on the mattes
>> and what kind of changes I'm willing to do to the MariaDB package.
>> Obviously I'd like to follow upstream as much as possible to keep the
>> delta between Debian and upstream small and thus the maintenance
>> burden reasonable

Attachment: signature.asc
Description: OpenPGP digital signature