Very Computer

But, when someone does a minor adjustment to the port, you don't have
to download again the whole (sometimes very large) original source,
only the update patch or build instructions, usually very small and
thus it is very easy and efficient to stay current (even more so
because of the excellent cvs/cvsup system).

With source RPM's, it seems you have to re-download the whole thing
(sometimes huge RPM's such as gcc) for every minor tweak.

Am I missing something? Is there a place where Redhat (or contrib)
source RPM's are located in unpacked form so that I can update without
downloading the whole original source over and over again?

TIA,

--
Peter Mutsaers |  Abcoude (Utrecht), | Trust me, I know

--
------------------------------------------------------------------

Suchandra S. Thapa

------------------------------------------------------------------

Quote:> Just download the patch
> and place it in the SOURCE directory and add the proper lines to the spec
> files (Patch[n]: patch.tar.gz where n is some integer at the top of the
> spec file and a corresponding %patch[n] -your_options_to_patch before the
> %build). Then after a rpm -bb your.spec or rpm -ba your.spec the binary
> rpm should appear in /usr/src/redhat/RPM  hierarchy and the source rpm in
> /usr/src/redhat/SRPMS.

really, it'd be very nice to have no-source rpms with just the spec
file and patches.

--
johan kullstam

Quote:

> >       If you do a rpm -Uvh or rpm -ivh to the source rpm then you
> > should get the tar.gz'ed source in the /usr/src/redhat/SOURCE directory
> > and the spec in /usr/src/redhat/SPEC directory.

> this presupposes that you already have the old source rpm.  if you do
> not, you have to 1) download the new source 2) download the old
> src-rpm.  note that step 2) contains the old sources which are 1)
> superceded by the new source and hence superflous and 2) often large.

Quote:

> > Just download the patch
> > and place it in the SOURCE directory and add the proper lines to the spec
> > files (Patch[n]: patch.tar.gz where n is some integer at the top of the
> > spec file and a corresponding %patch[n] -your_options_to_patch before the
> > %build). Then after a rpm -bb your.spec or rpm -ba your.spec the binary
> > rpm should appear in /usr/src/redhat/RPM  hierarchy and the source rpm in
> > /usr/src/redhat/SRPMS.

> sometimes hacking the spec file is a lot of trouble.  i spent a few
> hours hacking the egcs-1.1.2 rpm-spec file to make it do gcc-2.95.

> really, it'd be very nice to have no-source rpms with just the spec
> file and patches.

--
Bill Anderson                                   Linux/Unix Administrator, Security Analyst

My opinions are just that; _my_ opinions.

Quote:

> > >       If you do a rpm -Uvh or rpm -ivh to the source rpm then you
> > > should get the tar.gz'ed source in the /usr/src/redhat/SOURCE directory
> > > and the spec in /usr/src/redhat/SPEC directory.

> > this presupposes that you already have the old source rpm.  if you do
> > not, you have to 1) download the new source 2) download the old
> > src-rpm.  note that step 2) contains the old sources which are 1)
> > superceded by the new source and hence superflous and 2) often large.

> If the builder distributes patches, you only need to download the
> original src.rpm, and apply patches.
> Either way, if you do not have the source, you either download a binary,
> or you download the source.
> As seen below, this is precisely what the previous poster indicated.

Quote:> > > Just download the patch
> > > and place it in the SOURCE directory and add the proper lines to the spec
> > > files (Patch[n]: patch.tar.gz where n is some integer at the top of the
> > > spec file and a corresponding %patch[n] -your_options_to_patch before the
> > > %build). Then after a rpm -bb your.spec or rpm -ba your.spec the binary
> > > rpm should appear in /usr/src/redhat/RPM  hierarchy and the source rpm in
> > > /usr/src/redhat/SRPMS.

> > sometimes hacking the spec file is a lot of trouble.  i spent a few
> > hours hacking the egcs-1.1.2 rpm-spec file to make it do gcc-2.95.

> > really, it'd be very nice to have no-source rpms with just the spec
> > file and patches.

> Complain to the maintainer of the app.
> RPM is fully capable of these.

when you build from a spec, rpm makes binarary rpms and source rpms.
it does not make a package containing spec file and patches *without*
the main source tarball.

Quote:> It is up to whomever maintains the rpms (not always the same as whomever
> maintains the app) to distribute these.

i really like sources who are kind enough to include an
rpm spec file within the tarball.  this, an application maintainer,
can do.

--
J o h a n  K u l l s t a m

Don't Fear the Penguin!

    ST>      If you do a rpm -Uvh or rpm -ivh to the source rpm then you
    ST> should get the tar.gz'ed source in the /usr/src/redhat/SOURCE
    ST> directory and the spec in /usr/src/redhat/SPEC directory.
    ST> Just download the patch and place it in the SOURCE directory
    ST> and add the proper lines to the spec files (Patch[n]:
    ST> patch.tar.gz where n is some integer at the top of the spec
    ST> file and a corresponding %patch[n] -your_options_to_patch
    ST> before the
    ST> %build). Then after a rpm -bb your.spec or rpm -ba your.spec
    ST> %the binary
    ST> rpm should appear in /usr/src/redhat/RPM hierarchy and the
    ST> source rpm in /usr/src/redhat/SRPMS.

I know, but to do that you have first to download the whole updated
RPM. My problem is that the source RPM's aren't distributed as
separate orig-tarball, spec file, and patches. Thus, for every minor
update to the patches and/or specfile, you have to download the whole
SRPM again, which is terribly inefficient and wasteful.

--
Peter Mutsaers |  Abcoude (Utrecht), | Trust me, I know

Quote:

> > > >       If you do a rpm -Uvh or rpm -ivh to the source rpm then you
> > > > should get the tar.gz'ed source in the /usr/src/redhat/SOURCE directory
> > > > and the spec in /usr/src/redhat/SPEC directory.

> > > this presupposes that you already have the old source rpm.  if you do
> > > not, you have to 1) download the new source 2) download the old
> > > src-rpm.  note that step 2) contains the old sources which are 1)
> > > superceded by the new source and hence superflous and 2) often large.

> > If the builder distributes patches, you only need to download the
> > original src.rpm, and apply patches.
> > Either way, if you do not have the source, you either download a binary,
> > or you download the source.
> > As seen below, this is precisely what the previous poster indicated.

> what if the builder doesn't offer a patch.  you want to roll up a new
> rpm from the newer sources and wish to borrow from past rpm spec
> files.  you have to download the source twice.  it's annoying.

Quote:

> > > > Just download the patch
> > > > and place it in the SOURCE directory and add the proper lines to the spec
> > > > files (Patch[n]: patch.tar.gz where n is some integer at the top of the
> > > > spec file and a corresponding %patch[n] -your_options_to_patch before the
> > > > %build). Then after a rpm -bb your.spec or rpm -ba your.spec the binary
> > > > rpm should appear in /usr/src/redhat/RPM  hierarchy and the source rpm in
> > > > /usr/src/redhat/SRPMS.

> > > sometimes hacking the spec file is a lot of trouble.  i spent a few
> > > hours hacking the egcs-1.1.2 rpm-spec file to make it do gcc-2.95.

> > > really, it'd be very nice to have no-source rpms with just the spec
> > > file and patches.

> > Complain to the maintainer of the app.
> > RPM is fully capable of these.

> it's not.

Quote:

> when you build from a spec, rpm makes binarary rpms and source rpms.
> it does not make a package containing spec file and patches *without*
> the main source tarball.

An rpm will distibute whatever you tell it to.
If you want, you can have an *empty* rpm, or an rpm of config files, or
....

Quote:

> > It is up to whomever maintains the rpms (not always the same as whomever
> > maintains the app) to distribute these.

> i want a no-source rpm.  i want the source-less rpms to be found on
> ftp sites.  the application maintainer cannot change this situation
> one way or another.  (unless you are talking about the maintainer of
> the rpm application only.)

Quote:> i really like sources who are kind enough to include an
> rpm spec file within the tarball.  this, an application maintainer,
> can do.

--
Bill Anderson                                   Linux/Unix Administrator, Security Analyst

My opinions are just that; _my_ opinions.

--
Bill Anderson                                   Linux/Unix Administrator, Security Analyst

My opinions are just that; _my_ opinions.

Quote:> what if the builder doesn't offer a patch.  you want to roll up a new
> rpm from the newer sources and wish to borrow from past rpm spec
> files.  you have to download the source twice.  it's annoying.

With debian source archives you have:

source_version-debian_version.dsc
source_version-debian_version.diff.gz
source_version.orig.tar.gz

The .dsc file contains information about the package, a lot of it taken
from the debian/control file (a bit like the top part of a spec file, it
would seem), and a list of the other files in the source archive, with
size and md5sum information. The .dsc is PGP-signed by the maintainer.

The .orig.tar.gz contains the upstream source. None of the
debian-specific modifications in there.

Finally, the .diff.gz contains all of the debian changes from the
upstream source. This includes the debian/ directory, holding all the
information necessary to create a .deb package. It may also contain
patches to the source to conform with Debian policy, or to fix important
bugs until the upstream contains the fix.

If you have downloaded the source from the upstream maintainer
seperatly, all you need to download is the .diff.gz (and the .dsc if you
want to check the .diff.gz's authenticity). It's usually just a matter
of patching the source with this .diff, and compiling a debian package
as normal.

--
Chris Butler

    JK> what if the builder doesn't offer a patch.  you want to roll up a new
    JK> rpm from the newer sources and wish to borrow from past rpm spec
    JK> files.  you have to download the source twice.  it's annoying.

    JK> i want a no-source rpm.  i want the source-less rpms to be found on
    JK> ftp sites.  the application maintainer cannot change this situation
    JK> one way or another.  (unless you are talking about the maintainer of
    JK> the rpm application only.)

Indeed, that's just what I meant. I'm just surprised that no-source
rpm's aren't standard.

And the no-source RPM should also (in the spec-file) give a list of
URL's where the original tarball can be found. Then it can be
retrieved automatically if necessary, and stored in a cache
directory. This is more or less how FreeBSD works: the first time you
build a port the tarball is put in /usr/ports/distfiles, subsequent
times (assuming the port is still based on the same original release)
the tarball from /usr/ports/distfiles is automatically reused.

--
Peter Mutsaers |  Abcoude (Utrecht), | Trust me, I know

I personally find the debian method distasteful, both because of the
many files that are always floating around and because you can only
have a single diff file, whereas in an RPM can have multiple diff
files representing changes to various parts of the system, perhaps
supplied by different people.
--
David Fox           http://hci.ucsd.edu/dsf             xoF divaD
UCSD HCI Lab                                         baL ICH DSCU

Quote:>And the no-source RPM should also (in the spec-file) give a list of
>URL's where the original tarball can be found. Then it can be
>retrieved automatically if necessary, and stored in a cache
>directory. This is more or less how FreeBSD works: the first time you
>build a port the tarball is put in /usr/ports/distfiles, subsequent
>times (assuming the port is still based on the same original release)
>the tarball from /usr/ports/distfiles is automatically reused.

That would be a case where all that really needs to be transmitted
around is the patch file.

More common appears to be...

b) The "pristine sources" changed, mandating a new version number (and
not merely because we updated the RPM).

In this case, the whole tarball is needed.

There seems to be reasonably widespread agreement that RPM isn't the
best possible system that one might conceive of; I'm not convinced
that the situation being described represents a real good example of
"major problems with RPM."
--
"When we understand knowledge-based systems, it will be as before
-- except our fingertips will have been singed."  -- Alan Perlis

    CB> More common appears to be...

    CB> b) The "pristine sources" changed, mandating a new version number (and
    CB> not merely because we updated the RPM).

    CB> In this case, the whole tarball is needed.

I don't think this is more common. Following redhat rawhide, and even
only the major redhat releases, there are quite a number of very
stable packages that they keep tinkering with in the specfile or
patches only. Examples are emacs, gcc (for a long time, at the moment
with egcs/gcc-2.95 it is a bit less stable) gdb, many of the GNU
utilities. Of many of these the original source isn't changed for more
than a year, but every month or so a new RPM appears, fixing some
minor things or sometimes adding an important patch.

    CB> There seems to be reasonably widespread agreement that RPM isn't the
    CB> best possible system that one might conceive of; I'm not convinced
    CB> that the situation being described represents a real good example of
    CB> "major problems with RPM."

No, with Redhat, for not distributing in a convenient manner.

--
Peter Mutsaers |  Abcoude (Utrecht), | Trust me, I know

Peter> Coming from FreeBSD, I'm used to the ports system. It is a bit
Peter> like a source RPM: you have an original tarball, patches, build
Peter> instructions and a file list. This is handled automatically, then
Peter> packaged and installed.

Peter> But, when someone does a minor adjustment to the port, you don't
Peter> have to download again the whole (sometimes very large) original
Peter> source, only the update patch or build instructions, usually very
Peter> small and thus it is very easy and efficient to stay current
Peter> (even more so because of the excellent cvs/cvsup system). [ ... ]

Yeah, this annoys me too. However it is easy to explain: RPM design was,
and is, still dominated by the specific needs/incentives of RedHat
Inc. (down to the inane "/usr/src/redhat" structure): since RedHat SRPMS
come neatly on a CD when you buy an official RedHat boxed set, there is
absolutely no need to make downloading of SRPMSes faster.

I'd love too to have SRPMSes by default not incorporate the original
source archive, and download it separately; this can even be done, and
has been done, for packages whose source cannot be redistributed by
RedHat. But the default is still what suits the RedHat way of doing
things.