Bug 589316 - Config option history_record=0 is being ignored
Summary: Config option history_record=0 is being ignored
Alias: None
Product: Fedora
Classification: Fedora
Component: yum
Version: 13
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Seth Vidal
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2010-05-05 20:10 UTC by Bill Crawford
Modified: 2014-01-21 23:14 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2011-05-24 21:13:58 UTC
Type: ---

Attachments (Terms of Use)

Description Bill Crawford 2010-05-05 20:10:40 UTC
Description of problem:
Updates taking too long. Notice that /var/lib/yum/history is being updated (and this is taking a lot of extra time during transaction processing). This is even though I set the history_record=0 option in /etc/yum.conf ...

Version-Release number of selected component (if applicable):
Both the previous version (I can't remember the release number) and the current update (3.2.27-4.fc13) are exhibiting this problem.

How reproducible:
Start an update. Wait ... and wait ... and wait.

Steps to Reproduce:
1. Run "yum --noplugins --enablerepo local-updates-testing update"
2. Watch as it solves the dependencies, enter "y" and return.
3. Watch as it then takes over ten minutes to run the transaction (for seven packages).

Actual results:
Ten minute delay.

Expected results:
No ten minute delay.

Additional info:
I will, eventually, be replacing this PC with one that will cope with yum history and yum's other aspirations. However for the time being, I would like it to do what I ask it to. Being able to disable this "yumdb" (which is pretty pointless when most updates are being installed from updates-testing but end up in the development/13 repository, so the install source is meaningless) would be nice too. Please?

Comment 1 seth vidal 2010-05-05 20:41:08 UTC
10 minutes??

Can you please provide the output from any transaction like this of

yum -d 3 whateveryourunhere


Comment 2 Bill Crawford 2010-05-05 21:05:40 UTC
The ten minutes (actually 11) is because it's a rather old machine with just enough memory to run a desktop, and it wasn't the length of time that bothered me particularly, just that I thought I'd disabled the feature. The debug output shows nothing relating to the creation / update of the history database, I actually had to add some to figure out what was going on when I first ran into this problem - which was why I tried to turn it off in the config. I've also just edited the history out of my installed copy of yum so it wouldn't help much anyway ;o)

Comment 3 Bill Crawford 2010-05-05 21:08:02 UTC
... but I'll reinstall.

Comment 4 James Antill 2010-05-05 21:31:26 UTC
The feature is disabled, it's just that the feature only controls recording history transactions ... we still create the dir. and setup the history .sqlite file. This is because it's much easier to have a readable, but empty, history file than to have none at all.

Likely the time spent, is the "yum check" operations which are automatically done when we don't have a previous history file to test that nothing has changed since. I've just submitted a patch upstream to turn those off. To test that theory you can run:

yum check dependencies
yum check duplicates

...if those combined are your missing time, then that'll explain it. If you need to remove it quick I can tell you which lines to delete in __init__.py ... or just wait for 3.2.28 (or get a newer machine :).

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