Bug 859577 - yum: clean_requirements_on_remove too agressive, doesn't take Obsoletes into account
yum: clean_requirements_on_remove too agressive, doesn't take Obsoletes into ...
Product: Fedora
Classification: Fedora
Component: akonadi (Show other bugs)
Unspecified Unspecified
unspecified Severity urgent
: ---
: ---
Assigned To: Kevin Kofler
Fedora Extras Quality Assurance
: Reopened
Depends On:
  Show dependency treegraph
Reported: 2012-09-21 23:32 EDT by Garry T. Williams
Modified: 2014-01-21 18:23 EST (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2012-09-22 18:41:29 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Garry T. Williams 2012-09-21 23:32:07 EDT
Description of problem: Akonadi fails to start with the following message in the .xsession-errors file:

"Unable to add column 'version' to table 'SchemaVersionTable'.
Query error: 'Table 'akonadi.SchemaVersionTable' doesn't exist QMYSQL: Unable to execute query'"
Unable to initialize database.
0: akonadiserver(_Z11akBacktracev+0x34) [0x451d84]
1: akonadiserver() [0x4520c1]
2: /lib64/libc.so.6() [0x3333c359a0]
3: /lib64/libc.so.6(gsignal+0x35) [0x3333c35925]
4: /lib64/libc.so.6(abort+0x148) [0x3333c370d8]
5: /lib64/libQtCore.so.4(_Z17qt_message_output9QtMsgTypePKc+0x74) [0x3ade071234]
6: akonadiserver(_ZN15FileDebugStream9writeDataEPKcx+0x9b) [0x453d9b]
7: /lib64/libQtCore.so.4(_ZN9QIODevice5writeEPKcx+0xb4) [0x3ade10b294]
8: /lib64/libQtCore.so.4() [0x3ade115f3f]
9: /lib64/libQtCore.so.4(_ZN11QTextStreamD1Ev+0x3b) [0x3ade11e53b]
10: akonadiserver(_ZN7Akonadi13AkonadiServerC1EP7QObject+0x5e0) [0x455f60]
11: akonadiserver(_ZN7Akonadi13AkonadiServer8instanceEv+0x47) [0x457037]
12: akonadiserver(main+0x183) [0x44b483]
13: /lib64/libc.so.6(__libc_start_main+0xf5) [0x3333c21735]
14: akonadiserver() [0x44bde1]
ProcessControl: Application 'akonadiserver' returned with exit code 255 (Unknown error)

Version-Release number of selected component (if applicable): 


How reproducible: always

Steps to Reproduce:
1. akonadictl start

Additional info:

Fedora 17 and updated kde using updates-testing.  The first problem was that yum wanted to remove the mysql server due to dependencies.  I cancelled and reran yum with --setopt=clean_requirements_on_remove=0.  Then akonadi faied to start with:

Test 6:  ERROR

MySQL server default configuration not found.
Details: The default configuration for the MySQL server was not found or was not readable. Check your Akonadi installation is complete and you have all required access rights.

I copied the file with:

    sudo cp /usr/share/kde4/apps/digikam/database/mysql-global.conf /etc/akonadi

Now I get the error I'm reporting in this bug.

Here's what I have installed now:


Here's /etc/akonadi/mysql-global.conf:

# Global Akonadi MySQL server settings,
# These settings can be adjusted using $HOME/.config/akonadi/mysql-local.conf
# Based on advice by Kris Köhntopp <kris@mysql.com>

# strict query parsing/interpretation
# TODO: make Akonadi work with those settings enabled

# use InnoDB for transactions and better crash recovery
# TODO by foerster, This doesn't work - we need the default storage engine 
# case-insensitive table names, avoids trouble on windows
# error log file name, relative to datadir
# log all queries, useful for debugging but generates an enormous amount of data
# log queries slower than n seconds, log file name relative to datadir
# log queries not using indices, debug only, disable for production use
# maximum blob size
# makes sense when having the same query multiple times
# makes no sense with prepared statements and/or transactions

# messure database size and adjust
# SELECT sum(data_length) as bla, sum(index_length) as blub FROM information_schema.tables WHERE table_schema not in ("mysql", "information_schema");
# size of average write burst, keep Innob_log_waits small, keep Innodb_buffer_pool_wait_free small (see show global status like "inno%", show global variables)
Comment 1 Garry T. Williams 2012-09-22 18:01:05 EDT
Rex points out that installing akonadi-mysql will supply the missing conf file.

Furthermore, I found this in my local mysql.conf file:


I uncommented it and akonadi starts without the error.  That fixes the Unable to add column 'version' to table 'SchemaVersionTable' symptom.

I'm closing this bug NOTABUG, but the upgrade should have worked properly without me having to manually install akonadi-mysql.  It's also a mystery to me how my local mysql.conf got the statement commented out -- I don't even know if it was there before the upgrade.
Comment 2 Rex Dieter 2012-09-22 18:16:40 EDT
I think what we found here was a bug in the yum feature enabled with
(which is not default on, by the way).

The normal upgrade path *should* have gone something like this:

akonadi-1.7.x => akonadi-1.8.x + akonadi-mysql-1.8.x

since akonadi-mysql includes the rpm tags:
Obsoletes: akonadi < 1.7.90-2
Requires: %{name}%{?_isa} = %{version}-%{release}

except what happened instead was clean_requirements_on_remove=1 kicking in that
akonadi-1.7.x Requires: qt4-mysql mysql-server
akonadi-1.8.x does not
and it decided to remove those apprently no-longer-needed dependencies.

So, in short, the bug seems to be that 
apparently does not take Obsoletes into account before calculating what can be removed.  reopening and reassigning to yum.
Comment 3 Rex Dieter 2012-09-22 18:18:19 EDT
reassigning for real, apparently that clean_requirements_on_remove is too agressive, and doesn't take Obsoletes into accouny.  See comment #2 for further detail.
Comment 4 Garry T. Williams 2012-09-22 18:23:10 EDT
Just so you know, I cancelled the upgrade when I saw it wanted to erase mysql.  I then reran the command with --setopt=clean_requirements_on_remove=0 but this still resulted in akonadi-mysql missing in the upgrade.

I suspect that's because I said `update kde\*' on the yum command line.  Yes?
Comment 5 Rex Dieter 2012-09-22 18:41:29 EDT
Oh, so my analysis was incorrect, thanks for the clarification.

so yeah, since you only explicitly asked for kde\* that's exactly what you got, and akonadi-1.8 got pulled in via other versioned dependencies...  I don't think we can expect Obsoletes to get proper treatment in that scenario. :(

I guess back to NOTABUG we go.
Comment 6 Kevin Kofler 2012-09-22 18:47:09 EDT
> I suspect that's because I said `update kde\*' on the yum command line.  Yes?

Probably. That's the wrong way to do selective updates (also because kde\* is neither a necessary nor a sufficient criterion for a package to be a part of the KDE software compilation!), what you really want is:
yum install yum-security
yum --enablerepo=updates-testing --advisory=FEDORA-2012-14137 update
(and yes, yum-security actually works just fine on non-security updates like this one ;-) – it adds that --advisory switch).

But Rex, is making akonadi-mysql optional really worth all that pain?
Comment 7 Rex Dieter 2012-09-22 18:55:33 EDT
We use Obsoletes to help upgrade paths all the time.  If we're going to start doubting it's usefulness, then we have bigger problems.

Note You need to log in before you can comment on or make changes to this bug.