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 ...
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: akonadi (Show other bugs)
17
Unspecified Unspecified
unspecified Severity urgent
: ---
: ---
Assigned To: Kevin Kofler
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  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:
Environment:
Last Closed: 2012-09-22 18:41:29 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
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): 

akonadi-1.8.0-1.fc17.x86_64


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:

    akonadi-1.8.0-1.fc17.x86_64
    kdepimlibs-4.9.1-3.fc17.x86_64
    kdepimlibs-akonadi-4.9.1-3.fc17.x86_64
    kdepim-libs-4.9.1-1.fc17.x86_64
    kdepim-4.9.1-1.fc17.x86_64
    kdepim-runtime-libs-4.9.1-1.fc17.x86_64
    kdepim-runtime-4.9.1-1.fc17.x86_64

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>
#
[mysqld]
skip_grant_tables
skip_networking

# strict query parsing/interpretation
# TODO: make Akonadi work with those settings enabled
#sql_mode=strict_trans_tables,strict_all_tables,strict_error_for_division_by_zero,no_auto_create_user,no_auto_value_on_zero,no_engine_substitution,no_zero_date,no_zero_in_date,only_full_group_by,pipes_as_concat
#sql_mode=strict_trans_tables

# use InnoDB for transactions and better crash recovery
# TODO by foerster, This doesn't work - we need the default storage engine 
#default_storage_engine=innodb
# case-insensitive table names, avoids trouble on windows
#lower_case_table_names=1
character_set_server=latin1
collation_server=latin1_general_ci
table_cache=200
thread_cache_size=3
log_bin=mysql-bin
expire_logs_days=3
#sync_bin_log=0
# error log file name, relative to datadir
log_error=mysql.err
log_warnings=2
# log all queries, useful for debugging but generates an enormous amount of data
#log=mysql.full
# log queries slower than n seconds, log file name relative to datadir
log_slow_queries=mysql.slow
long_query_time=1
# log queries not using indices, debug only, disable for production use
log_queries_not_using_indexes=1
# maximum blob size
max_allowed_packet=32M
max_connections=256
# makes sense when having the same query multiple times
# makes no sense with prepared statements and/or transactions
query_cache_type=0
query_cache_size=0

innodb_file_per_table=1
innodb_log_buffer_size=1M
innodb_additional_mem_pool_size=1M
# 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");
innodb_buffer_pool_size=80M
# 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)
innodb_log_file_size=64M
innodb_flush_log_at_trx_commit=2
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:

    #lower_case_table_names=1

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
clean_requirements_on_remove=1
(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
and 
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 
clean_requirements_on_remove=1
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.