Bug 56441 - up2date bombs out if it cannot download associated source RPM for a selected package
up2date bombs out if it cannot download associated source RPM for a selected ...
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: up2date (Show other bugs)
4.0
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Adrian Likins
Jay Turner
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-11-18 10:00 EST by Ray Price
Modified: 2015-01-07 18:53 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2002-04-29 19:01:05 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 Ray Price 2001-11-18 10:00:47 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011012

Description of problem:
up2date allowed me to select
xinetd-2.3.3-1.i386.rpm
anonftp-4.0-9.i386.rpm 

to update, by default I have download the associated source package selected.

When up2date attempts to download the source RPMs for these packages it
error's and cancels the entire update process.

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


How reproducible:
Always

Steps to Reproduce:
1. Be able to update to the mentioned RPM packages (as I know the source
RPM for them does not exist)
2. Try to update to them.
3. On trying to download the source RPM packes up2date errors and cancels
the entire process.
	

Actual Results:  up2date errors and cancels the entire process.

Expected Results:  The erro should be logged or message'd boxed - I don't
expect the entire process to cancel as it mines I have to download these
packages seperatly. Doing this is not a good user experience :-)

Additional info:

To work around this in my copy, I changed up2date.py such that...

def getPackage(pkg, msgCallback = None, progressCallback = None):
...
    if cfg.readEntry("retrieveSource"):
        s = getServer()
        try:
            pkgStream = up2date.source_package_by_name(getSystemId(),
                                                         hdr['SOURCERPM'])
....
        except xmlrpclib.Fault, f:
**            if f.faultCode == -17:
**                log.log_me("Failed: %s" % f.faultString)
**                return 1
**            else:
                raise CommunicationError(f.faultString)
Added the ** lines so that the cannot download error for a source RPM does
not cancel the entire process.

Works for me!! :-)

I'm sure something better can be done with the error.
Comment 1 Adrian Likins 2001-11-19 12:07:16 EST
Well, if you cant download the src rpms the user asked for, I think
throwing up an error message is the correct thing to do for now. Ideally
we would throw up an error message and have some way to ignore it if
we like, but that will have to wait for the next version.

The real question is "why are source rpm downloads failing?"


Comment 2 David M. Cook 2002-04-17 20:42:00 EDT
The problem with ignoring missing source packages is: what status code do you
return when up2date exits?  It would need to be non-zero to be useful for
testing.  Admittedly, this is only a problem for testers, and a testers problem
shouldn't really be made a users problem.
Comment 3 Greg DeKoenigsberg 2002-04-29 19:01:00 EDT
So is it a bug or ain't it a bug?
Comment 4 Adrian Likins 2002-05-15 16:15:10 EDT
not a bug... if the download fails:

a). up2date didnt do what the user wanted. Thats a failure and shouldnt
    be ignore.

b) It means something is wrong with the server, and should be fixed.

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