Why so inefficient source RPM's ??

Why so inefficient source RPM's ??

Post by Peter Mutsaer » Tue, 17 Aug 1999 04:00:00



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

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

 
 
 

Why so inefficient source RPM's ??

Post by Suchandra Tha » Thu, 19 Aug 1999 04:00:00



>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?

        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.  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.

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

Suchandra S. Thapa

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

 
 
 

Why so inefficient source RPM's ??

Post by Johan Kullsta » Thu, 19 Aug 1999 04:00:00




> >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?

>    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.

--
johan kullstam

 
 
 

Why so inefficient source RPM's ??

Post by Bill Anderso » Thu, 19 Aug 1999 04:00:00





> > >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?

When you download and install foo-1.0.i386.rpm, you are not installing
source (unless the builder totally messed up :).
When foo-1.1 comes out, and you get and install foo-1-1.i386.rpm, again,
no source is downloaded, just whatever is needed to run soo (along with
documentation usually).

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.
It is up to whomever maintains the rpms (not always the same as whomever
maintains the app) to distribute these.

--
Bill Anderson                                   Linux/Unix Administrator, Security Analyst

My opinions are just that; _my_ opinions.

 
 
 

Why so inefficient source RPM's ??

Post by Johan Kullsta » Thu, 19 Aug 1999 04:00:00






> > > >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?

> When you download and install foo-1.0.i386.rpm, you are not installing
> source (unless the builder totally messed up :).
> When foo-1.1 comes out, and you get and install foo-1-1.i386.rpm, again,
> no source is downloaded, just whatever is needed to run soo (along with
> documentation usually).

read the subject.  we are talking *source* RPMs here.

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.

- Show quoted text -

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.

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 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.)

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!

 
 
 

Why so inefficient source RPM's ??

Post by David F » Thu, 19 Aug 1999 04:00:00



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

> it's not.

> 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.

> > 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.)

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

The RPM system is quite capable of creating no-source RPMS, but it is
extra work for the application maintainer.  What you really want is a
way to remotely extract and retrieve the spec file from a regular RPM,
and then to extract and retrieve individual sources and patches.  You
could then build a tool to update a local source RPM from a remote
source RPM.
--
David Fox           http://hci.ucsd.edu/dsf             xoF divaD
UCSD HCI Lab                                         baL ICH DSCU
 
 
 

Why so inefficient source RPM's ??

Post by Peter Mutsaer » Thu, 19 Aug 1999 04:00:00


    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

 
 
 

Why so inefficient source RPM's ??

Post by Bill Anderso » Fri, 20 Aug 1999 04:00:00








...

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.

And if the maintainer does not distibute patches, and distributes in
tarball, you have to download the news source there to. Same with *any*
system if you don't have patches available, with the exception of CVS.

- Show quoted text -

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.

Yes, it is.

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.

Then perhaps you should tell that to my no-source rpms?

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.)

Whomever is making the rpm for that particular application is who to
talk to about no-source rpms.
RPM *is* fully capable of doing this.

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

Yes, they can. And they can use rpm to do it. It is not always the case
that the person who makes the rpm is the maintainer of the software. In
either event, rpm is fully capable of what you are wanting, and there
are those that *do* do this, myself included. Again, if a particular app
does not, complain to the maintaner of the rpm.

--
Bill Anderson                                   Linux/Unix Administrator, Security Analyst

My opinions are just that; _my_ opinions.

 
 
 

Why so inefficient source RPM's ??

Post by Bill Anderso » Fri, 20 Aug 1999 04:00:00




>     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.

And is not a failing of rpm. As said elsewhere, rpm is fully capable of
doing this.
Do not confuse lack of performance on a maintainer's part with inability
of rpm.
complain to the maintainer of the source or rpm builder, as appropriate.

--
Bill Anderson                                   Linux/Unix Administrator, Security Analyst

My opinions are just that; _my_ opinions.

 
 
 

Why so inefficient source RPM's ??

Post by Chris Butl » Fri, 20 Aug 1999 04:00:00


[comp.os.linux.development.system - 18 Aug 1999 17:44:42 -0400]
  * Johan wrote *

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.

Not wanting to start dist-wars here, but Debian handles this a bit
better.

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

 
 
 

Why so inefficient source RPM's ??

Post by Peter Mutsaer » Fri, 20 Aug 1999 04:00:00


    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

 
 
 

Why so inefficient source RPM's ??

Post by David F » Fri, 20 Aug 1999 04:00:00



> 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?

This is only a problem if you are dealing with a package that is (a)
huge and (b) updated frequently and (c) you need to follow every
little update and (d) you only have a low bandwidth connection to the
net.  Furthermore, we are only talking about changes to the RPM
specfile, not to the underlying package.  This is such an unusual
situation that it is my opinion that the advantages of the usual
source+specfile RPM packaging method far outweigh the disadvantages.
In the rare case where it is a problem there is a completely standard
RPM feature you can use to build a no source RPM.

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

 
 
 

Why so inefficient source RPM's ??

Post by Christopher Brow » Sat, 21 Aug 1999 04:00:00




>    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.

Are you sure that's what you meant to say?

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.

The problem is that there are two behaviours:
a) A further patch was needed to fix some odd behaviour with a
package, thereby bumping up the "most-minor" version number, but not
requiring any new "pristine sources."

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

 
 
 

Why so inefficient source RPM's ??

Post by Peter Mutsaer » Sat, 21 Aug 1999 04:00:00


    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

 
 
 

Why so inefficient source RPM's ??

Post by Piercarlo Gran » Sat, 21 Aug 1999 04:00:00


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.

 
 
 

1. Why so inefficient source RPM's ??

[comp.os.linux.development.system - 18 Aug 1999 17:44:42 -0400]
  * Johan wrote *

Not wanting to start dist-wars here, but Debian handles this a bit
better.

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

2. HTACCESS generator question!

3. why won't scripts work unless i 'source' them?

4. lint pass2

5. Gnome - rpm's or source tar's - Which is best?

6. What is "LABEL" in fstab and how do I change partition for /usr and /var

7. why does 'which' source my csh?

8. DHCP server available for Linux?

9. rpm: not found 'packages.rpm'

10. RPM doesn't create any RPM's

11. Pb rebuild SRC.RPM : cannot create //root/rpm/SOURCES

12. suse rpm's vs. RH rpm's

13. Why does G-RPM install no RPM packages ?