Bug 338161 - "Cannot find a source rpm" but it is cached
"Cannot find a source rpm" but it is cached
Status: CLOSED UPSTREAM
Product: Fedora
Classification: Fedora
Component: pungi (Show other bugs)
rawhide
All Linux
low Severity low
: ---
: ---
Assigned To: David Cantrell
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-10-18 11:54 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-10-18 14:36:26 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description John Reiser 2007-10-18 11:54:05 EDT
Description of problem: Pungi aborts because it cannot find a src rpm, but the
src rpm is in the pungi cache.  [/var/cache/pungi is symlinked to a directory on
another filesystem for space reasons, but that should not matter.  The target of
the symlink is on the same filesystem as --destdir.]


Version-Release number of selected component (if applicable):
pungi-1.1.5-1.fc8


How reproducible: always


Steps to Reproduce:
1. rm -rf /data/Fedora8
2. edit /usr/share/pungi/f8-fedora.ks to have "part iso --size=650"
3. pungi -c /usr/share/pungi/f8-fedora.ks --destdir=/data/Fedora8 --name Fedora
--ver 8 --discs 3
  
Actual results:
[snip]
Pungi.Gather:INFO: Running /usr/bin/xsltproc --novalid -o
/data/Fedora8/work/i386/Fedora-8-comps.xml /usr/share/pungi/comps-cleanup.xsl
/data/Fedora8/work/i386/Fedora-8-comps.xml
Error: Cannot find a source rpm for selinux-policy-3.0.8-22.fc8


Expected results: no complaint


Additional info:
# ls -l /var/cache/pungi      ### symlink for disk space
lrwxrwxrwx 1 root root 21 2007-10-18 07:44 /var/cache/pungi -> /data/var-cache-pungi
# find /data/var-cache-pungi -name selinux-policy'*'
/data/var-cache-pungi/selinux-policy-targeted-3.0.8-24.fc8.noarch.rpm
/data/var-cache-pungi/selinux-policy-targeted-3.0.8-22.fc8.noarch.rpm
/data/var-cache-pungi/selinux-policy-3.0.8-22.fc8.noarch.rpm
/data/var-cache-pungi/selinux-policy-3.0.8-22.fc8.src.rpm     <<<<< there it is
/data/var-cache-pungi/selinux-policy-mls-3.0.8-24.fc8.noarch.rpm
/data/var-cache-pungi/selinux-policy-3.0.8-24.fc8.noarch.rpm
/data/var-cache-pungi/selinux-policy-mls-3.0.8-22.fc8.noarch.rpm
# ls -l /data/var-cache-pungi/selinux-policy-3.0.8-22.fc8.src.rpm
-rw-r--r-- 1 root root 623952 2007-10-13 07:31
/data/var-cache-pungi/selinux-policy-3.0.8-22.fc8.src.rpm
# ls -l /var/cache/pungi/selinux-policy-3.0.8-22.fc8.src.rpm
-rw-r--r-- 1 root root 623952 2007-10-13 07:31
/var/cache/pungi/selinux-policy-3.0.8-22.fc8.src.rpm
#
Comment 1 Jesse Keating 2007-10-18 13:30:00 EDT
This is on purpose.  We don't look in the cache to find packages, we look in the
/repos/ to find the right packages and then at the download step if we happen to
have a matching package in the cache that matches the checksum and all that we
will use the cached package instead of downloading a new one.  If it can't find
a reference to the package in a yum repo that is a failure.
Comment 2 John Reiser 2007-10-18 13:59:12 EDT
Request for enhancement: Please change the error message to indicate more
precisely what is wrong.  Such as: "selinux-policy-3.0.8-22.fc8.src.rpm is not
listed in repos (see repo list in
/data/Fedora8/work/i386/yumcache/*/repomd.xml)".  I expect the error message to
give me enough information so that I can verify independently whether a package
is missing, and give me hints as to how I can recover.

In this particular case, I can find selinux-policy-3.0.8-24.fc8.src.rpm [note
the "-24" instead of "-22"] on the mirrors.  Does this mean that the metadata is
bad, or that the mirrors just have not sync'ed yet, or what?
Comment 3 Jesse Keating 2007-10-18 14:36:26 EDT
Sure, I can change the error string, that's not a big deal.

It could very well be that the mirror is syncing, and isn't using
--delete-after, and/or two stage syncing (first the bits, then the metadata w/
delete).  So you've got metadata that references one package and on the
filesystem is a different package.

I've filed this in upstream pungi Trac to erm track it there.

https://hosted.fedoraproject.org/projects/pungi/ticket/54

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