Bug 6346 - RFE: rpm should try to download missing source files
RFE: rpm should try to download missing source files
Status: CLOSED WONTFIX
Product: Red Hat Linux
Classification: Retired
Component: rpm-build (Show other bugs)
7.1
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jeff Johnson
: FutureFeature
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 1999-10-25 15:32 EDT by Aleksey Nogin
Modified: 2007-04-18 12:24 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-05-21 10:53:18 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 Aleksey Nogin 1999-10-25 15:32:49 EDT
Currently (version 3.0.2) rpm prints an error message and
quits when it is asked to build a package and one of the
source or patch files is missing.

It would be really nice if when the source/patch file is
specified using the full URL, then instead of printing an
error message, rpm would ask if the missing file should be
downloaded.

This would enable faster building of the new versions of
packages - when the source location is specified correctly
(using %{version} macro if necessary), you would only need
to update the version field in the spec file and run "rpm
-ba" and the new sources would be dowloaded by rpm
automatically.
Comment 1 Jeff Johnson 2000-08-07 09:45:54 EDT
This problem will be addressed after rpm-4.0 is released.
Comment 2 Jeff Johnson 2001-02-22 17:17:21 EST
Changing component
Comment 3 Jeff Johnson 2001-08-30 15:04:13 EDT
Automatic source/patch downloads aren't what's needed, but
rather an integrated, network aware, rpm build environment
that can download configuration, spec files, components,
build system assignments, and post build disposition.
Comment 4 Aleksey Nogin 2002-11-05 23:52:50 EST
Any chance this can be reopened? While a fully integrated environment is great,
inplementing just this one feature will make things better for people. After
all, the rpm inself is capable of downloading and installing packages straight
off ftp/http - why not add the same thing to rpmbuild?

Also, the source location is often specified with the help of macros - so
downloading manually is not too convenient and any "external" tool will need to
be able to understand rpm macros (at least in some limited way), while rpmbuild
already knows what the location is and just needs to be able to download the file.
Comment 5 Bishop Clark 2003-11-06 17:18:28 EST
can't the same functionality be faked with a really crafty %eval?

%define      mysource1     http://www.some.net/path/to/file.tgz
SOURCE1:     %mysource1
%define source1good %( [ ! -f %{S:1} ] && wget -q --dir %_sourcedir
%{mysource1} || : )

admittedly, that hack is just that, but a corrected version of the
above may bring you short-term bliss.


Comment 6 R P Herrold 2004-03-02 14:26:55 EST
A couple comments on the proposal:

1. the concept of 'prompting' within an RPM family tool, is outside of
the design space of RPM.  It should not happen for htat reason alone.

2. The issue of an automatic, or unattended download, using wget, or
otherwise, is full of security issues -- Monkey-in-the-Middle attacks,
with compromised DNS, faked CA, compromised remote (or MitM made)
archives, and the sort appear to be unsolveable absent finding a
method to find, and on an automated basis, trusting a signed md5sum
hash against the expected value.  Obviously the md5sum cannot be
carried within the Source url, as it is produced externally and after
a tarball is rolled.

Several approaches have emerged -- PDR, mezzanine, the cAos
buildsystem, and the pre- and post-RH fedora variants.  These seem 
closer to the 'correct' space for such approaches to be applied.

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