Hi,

We don't document workarounds for issues like MDEV-3882 because they are considered high-priority bugs and are being worked on, with the goal, as you said, to make it eventually work by simply adding a repository to the configuration. If you encountered other bugs in MariaDB packaging, please also file them here in JIRA.

If you noticed any problems which are not exactly MariaDB bugs, but make installation of MariaDB difficult, please describe here what happens (and if you found a solution, then what it is) so we could indeed document it.

Thank you.

Hi,
I understand your vision of the problem, but here are a few points that I believe can motivate you to better understand the user's experience :

1) Once we break mariadb it is to late to just easily reapply the fixes that MDEV-3882 might bring
2) If one simply sets up mariadb, one has no clue that (s)he is at risk to waste hours in order to solve a poorly doucmented known issue
3) For various reasons (php, phpmyadmin...) mariadb is at risk to fail upgrades and has already done so several times in one year for me and others.
4) The solution you point at doesn't help nor rewards the people that switched to mariadb as you infer that we should wait for a better mariadb (since packaging is 101 in getting/keeping Mariadb up and running)

If this can get you started.....
This is what I use for pining :
Package: libmysqlclient18
Pin: origin mirror2.hs-esslingen.de
Pin-Priority: 1000

And this command line to "reinstall" :
apt-get install mariadb-server-5.5 mariadb-client-5.5 \
mariadb-server-core-5.5 mariadb-common mariadb-server \
libmariadbclient18 libdbd-mysql-perl mariadb-client-core-5.5 \
libmysqlclient18=5.5.28-mariadb-a1~precise \
mysql-common=5.5.28-mariadb-a1~precise

Anyway, as I said I understand your point so feel free to close this.

Thank you.

Hi,

See some comments inline.

>> 2) If one simply sets up mariadb, one has no clue that (s)he is at risk to waste hours in order to solve a poorly doucmented known issue

I understand your concern. But please keep in mind MDEV-3882 is not a "known issue" as it's usually referred to (as "something we know doesn't work quite as it should, but we aren't sure when we're going to fix it, if ever, so just live with it"). It was discovered after 5.5.28 was released, and is planned to be fixed in 5.5.29 release. That's the reason why it's not officially documented – it's just an open bug in progress; one can go to the bug tracking system which is available to everyone, and check open bugs in there, that's how bugs are documented.

>> 4) The solution you point at doesn't help nor rewards the people that switched to mariadb as you infer that we should wait for a better mariadb (since packaging is 101 in getting/keeping Mariadb up and running)

It's only true to some extent. If one's requirement is to have it work out-of-box, then indeed, there is no magic solution: bug is a bug, it needs to be fixed, and until it is, installation won't work smoothly. However, if one is willing to install it nevertheless, there are workarounds, and they are being discussed in different sources: https://lists.launchpad.net/maria-discuss/msg00698.html https://kb.askmonty.org/en/drop-in-replacement-on-debian/ (you already mentioned one).

>> 3) For various reasons (php, phpmyadmin...) mariadb is at risk to fail upgrades and has already done so several times in one year for me and others.

Yes, I guess life of our users would have been a lot easier if mariadb was in official repositories and thus was upgraded in sync with other related products; but that's not the case, so we have to keep up with the whole universe of systems, environments, setups and configurations. That's where we need the active community the most. If people report issues they encounter during installation or upgrades, we try to do our best to fix them; if they don't, we might never even know about them.

>> 1) Once we break mariadb it is to late to just easily reapply the fixes that MDEV-3882 might bring
Your data directory should stay safe, broken dependencies can be fixed, so while I agree it's a big nuisance to do cleanup after bad installation, nothing disastrous should have happened. If it did, please provide more details.

This last point is why I'm keeping it open for now, despite your suggestion to close it.

Hi,
for point 1), data is safe of course but disaster is a matter of standpoint, something I faill to make you understand. We are end-users of your product (with backups, snapshots, vm and what not) so of course our data is safe anyway...

...But please read this release note :
"MariaDB 5.5.28a includes a fix for CVE-2012-5611, a vulnerability that allowed an authenticated user to crash MariaDB server or to execute arbitrary code with the privileges of the mysqld process. This is a serious security issue. We recommend upgrading from older versions as soon as possible."

How come you don't see as disastrous the concequence of a faulty packaging in mariadb.
I never experienced those issues and never lost anything because of some package error. Therefore you're welcome to close this as per data directory concerns.

With some sense of humour, one could put an asterisks on that release note? *This upgrade will also prevent anybody else from accessing your data....

Still I believe that Mariadb tourists (following suggested "easy" apt-get upgrade ways) are back to running something else. Again, this is not my case and I strongly advise people to consider Mariadb. Always. I just feal bad when something like this happens.

Thank you for this open discussion.

>> How come you don't see as disastrous the concequence of a faulty packaging in mariadb.

That's because we consider it critical. Critical is what makes people try to fix it asap, disastrous is what just makes them feel all sad and hopeless.

We are indeed very sorry for any inconvenience that the problem has brought to users, as we always are about any bugs, but the best we can do now is fix it.

Closing as a duplicate of MDEV-3882, which it is, all in all.

Hi Daniel,

Since 5.5.29 only provides a temporary solution for MDEV-3882, and besides we still have an issue with Percona => MariaDB crossgrade, I think this documentation request makes all sense now (not that it didn't before, but there was not much point at documenting a one-version bug). You already explained the workaround e.g. in here https://lists.launchpad.net/maria-discuss/msg00698.html , it works okay for the main server or Galera installation, as well as Percona=>MariaDB. Could we put it somewhere in KB where it's easy to find? FAQ, installation instructions, etc., maybe even several places, along with a suggestion to run apt-get install -f , dpkg --configure -a , apt-get autoremove and whatever else to make sure the user's system isn't in a half-configured state by the time they start installation.

Thanks.

Hi,
This is much better and thorough enough.

Thank your for your time.

Documentation updated, so closing issue.