Bug 73358 - up2date --src dies when .src.rpm is missing
up2date --src dies when .src.rpm is missing
Product: Red Hat Public Beta
Classification: Retired
Component: up2date (Show other bugs)
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Adrian Likins
Jay Turner
Depends On:
  Show dependency treegraph
Reported: 2002-09-03 10:00 EDT by Bill Rugolsky, Jr.
Modified: 2015-01-07 19:00 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2002-09-03 10:00:44 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Bill Rugolsky, Jr. 2002-09-03 10:00:37 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc3) Gecko/20020523

Description of problem:
For some reason, the source packages corresponding to some of the binary rpms
appear to be missing, e.g., glibc-2.2.90-2.src.rpm.  When up2date attempts to
download these, it cannot find them.  I've been working around it by linking a
dummy .src.rpm under the name, but this requires restarting up2date.  It would
be preferable to have an option to ignore this particular error.  But why are
the packages not there?

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


How reproducible:

Steps to Reproduce:
1.up2date --nosig --src -u

Actual Results:  Dies when a required source rpm is not found.  Updating from the
original null install, the following are missing:


Expected Results:  All source rpms ought to be present.  Failing that, the program
should be able to proceed gracefully.

Additional info:

I tried to update up2date first, but it kept generating an (unrelated)
backtrace, so I downgraded back to the version from the iso.
Comment 1 Adrian Likins 2002-09-12 17:49:40 EDT
beta issue. The src rpms werent pushed along with the bin rpms to
the channel. 

Generally, I consider 404's as fatal errors, since it means that
what the user requested be done can not be accomplished.
Comment 2 Bill Rugolsky, Jr. 2002-09-13 11:13:06 EDT
It still seems to me that one ought to attempt to download all the packages,
total up the number of errors, and die with a count of the missing packages. 
It's a UI bug: if I ask up2date to download a gigabyte of data while I go to
dinner, and I come back to find that's it only retrieved 1% of said data when
99+% was available, I'm greatly annoyed.  How about a simple flag to continue

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