Description of problem: The created DVD [or CDs] from running pungi contains multiple versions of the same .rpm package. Examples: elfutils-0.129-2.fc8.i386.rpm elfutils-0.130-3.fc8.i386.rpm fedorainfinity-gdm-theme-8.0.0-1.fc8.noarch.rpm fedorainfinity-gdm-theme-8.0.1-1.fc8.noarch.rpm Version-Release number of selected component (if applicable): pungi-1.1.6-1.fc8 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.