Red Hat Bugzilla – Bug 346031
install media has multiple versions of same .rpm package
Last modified: 2013-01-09 20:42:40 EST
Description of problem: The created DVD [or CDs] from running pungi contains
multiple versions of the same .rpm package. Examples:
Version-Release number of selected component (if applicable):
How reproducible: always
Steps to Reproduce:
1. Run the EXAMPLE from the manual page: "pungi -c /usr/share/pungi/f8-fedora.ks
--destdir=/data/Fedora8 --name Fedora --ver 8"
2. On subsequent days, clean out the --destdir directory: "rm -rf
/data/Fedora8" (but leave the pungi cache alone), then re-run step 1. Cleaning
out the --destdir is necessary because pungi is clumsy about existing files and
directories (Bug #336901).
3. Repeat step 2 for several days as updated packages are released.
Actual results: pungi cache accumulates multiple versions of the same .rpms,
which is fine because some components file might specify an exact old version,
for instance. But the output DVD also contains multiple versions of the same
.rpms, and this is not OK because it wastes space on media, time during pungi,
and time during install.
Expected results: Ouput media contains only one version of the .rpm for any
given package [and $ARCH and sub-$ARCH: .i386, .i586, .i686 versions of "same"
package are OK]
Additional info: /var/cache/pungi is symlinked to /data/var-cache-pungi for
reasons of disk space.
Is there an easy command to remove from the cache .rpms that have been
superseded? Flushing the cache of all .rpms is too expensive because of the
time needed to re-download the .rpms that could have been kept. (Requiring a
flush as a workaround would make it unlikely for me to use pungi. I get
550MB/hr, so 3GB .rpm plus 3GB .srpm would take half a day or so.)
Hrm, there very well could be a bug lurking in the pungi yum code that I just
haven't seen as I'm always pointed at rawhide where there is only one build of
each package, no possibility for dupes.
And no, there is no command to prune the cache because as you said, you may be
composing multiple targets and using the same cache (like F7 respins and F8 and
F9) so the concept of 'superseded' is not there. For now I leave it up to the
person using the tool to prune as it makes sense for them and their cache.
Btw you can override the default cache location with --cachedir, so you could
even implement cachedirs per target and be able to prune out all but the latest
build of a package from each target cache.
Filed and tracked as https://hosted.fedoraproject.org/projects/pungi/ticket/59
I just tried doing multiple composes that reference both the Fedora 8 release
repo and the updates repo, where there is plenty of opportunity for duplication.
However in each run, only the latest version of packages are being pulled in,
I'm seeing no duplication, including the packages you mentioned above. Are you
still seeing this issue?
Works for me, too. pungi-1.1.9-1.fc8 on i686.