Bug 346031 - install media has multiple versions of same .rpm package
install media has multiple versions of same .rpm package
Status: CLOSED WORKSFORME
Product: Fedora
Classification: Fedora
Component: pungi (Show other bugs)
rawhide
All Linux
low Severity low
: ---
: ---
Assigned To: David Cantrell
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-10-22 17:01 EDT by John Reiser
Modified: 2013-01-09 20:42 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-11-15 15:45:38 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description John Reiser 2007-10-22 17:01:52 EDT
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.)
Comment 1 Jesse Keating 2007-10-22 17:15:08 EDT
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.
Comment 2 Jesse Keating 2007-11-15 15:45:38 EST
Filed and tracked as https://hosted.fedoraproject.org/projects/pungi/ticket/59
Comment 3 Jesse Keating 2007-11-26 16:07:40 EST
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?
Comment 4 John Reiser 2007-11-26 18:22:23 EST
Works for me, too.  pungi-1.1.9-1.fc8 on i686.

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