Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 230483 - pkgorder should not use persistent cache dir
Summary: pkgorder should not use persistent cache dir
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: yum
Version: 5.0
Hardware: All
OS: Linux
Target Milestone: ---
: ---
Assignee: James Antill
QA Contact:
Depends On:
Blocks: FC7Target
TreeView+ depends on / blocked
Reported: 2007-02-28 22:51 UTC by Jos Vos
Modified: 2009-03-25 05:58 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2009-03-25 05:58:37 UTC
Target Upstream Version:

Attachments (Terms of Use)

Description Jos Vos 2007-02-28 22:51:12 UTC
Description of problem:
When running pkgorder (or buildinstall, calling pkgorder) multiple times with
different repository contents (i.e. replacing packages), it seems to get
confused and it ignores the new packages.  This is probably due to the fact that
the "anaconda" repos info is kept in /var/cache/yum.  The anaconda repos is
defined in the temporary yum.conf file created by pkgorder and multiple anaconda
repositories should not be related to each other using the same cache.

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

Comment 1 Jeremy Katz 2007-03-01 16:27:13 UTC
That shouldn't be the case -- we get a temporary cache dir under /var/tmp to use
for all of the repo information in pkgorder (see cachedir = yum.misc.getCacheDir())

Can you try to get a better idea of what's going wrong?

Comment 2 Jos Vos 2007-03-03 15:09:38 UTC
What if /var/yum/cache already contains info about a repo named "anaconda"? 
Would that maybe be used anyway?  What I did was, while testing, a "yum -c
tmp.conf ...", similar to the temporary conf file in pkgorder, so this created
info for "anaconda" in /var/cache/yum.

What I remember (not 100% sure anymore):

-  Runnning pkgorder for a repo -> output ok.
-  Replacing two packages in the repo by new releases (same package
names/versions, different release number).
-  Running createrepo.
-  Running pkgorder again -> output list is missing the two new packages I just
replaced (also the old versions are not listed).
-  Adapting pkgorder to include "cachedir=/dev/null" in the temporary yum.conf
file and/or "rm -rf /var/cache/yum/anaconda" solved the problem.

To be sure about what actually solved the problem, I need to redo the whole
sequence and see if I can reproduce it.

Comment 3 Jeremy Katz 2007-03-05 20:37:12 UTC
Bah, the getCacheDir() stuff will reuse an existing one and not always do a

Comment 4 Jos Vos 2007-05-19 15:33:13 UTC
When I "rm -rf /var/tmp/yum-*" before calling buildinstall/pkgorder, everything
works fine.  I saw that the /var/tmp/yum-root-.../anaconda/headers directory
contained the *sum* of two totally different repos header sets for which I once
had called pkgorder :-(.  The second run of pkgorder got completely confused,
ran for 30 minutes or so, and produced incomplete output.

Comment 5 Red Hat Bugzilla 2007-08-21 05:32:12 UTC
User's account has been closed

Comment 6 James Antill 2008-04-18 14:17:28 UTC
 wth ... I don't even know what pkgorder is ... but it sounds like it's abusing
getCacheDir(). One of the points of that function is that it's stable across
multiple runs, so that people don't have to re-download their repo. MD each time
they run a command.
 You could set your metadata_expire to 0, so that the yum code will check it.
But I can't see a good case for yum deleting the cache dir.

 This needs to be assigned to someone/something else or closed NaB, from what I
can see right now.

Comment 7 James Antill 2009-03-25 05:58:37 UTC
closing due to none responce ... but the 5.4 errata will have the getCacheDir() changes requested by Jesse. So you can make truley temporary directories now.

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