On Thu, 17 Aug 2000, John Summerfield wrote:
>> 1 in 100000 users that look at 1-5 out of the 2000 .spec files
>> that would be installed, would then have to get some src.rpm code
>> likely to get going anyway. After they've learned what they
>> could from the spec file (about 15 seconds worth) they would have
>> little use for them anymore. .spec files are not documentation
>> on how to build packages. The HOWTO is a start, and the book
>> Maximum RPM is a finish. The book is free download from rpm.org.
>
>When last I looked, Maximum RPM was seriously out of date; it applies to rpm
>2.x and 3 is very different, and presumably 4.0 will make obsolete anything
>anyone's writing/written for 3.
Maximum RPM is out of date, but is still good for learning how to
get started. I still use it for reference myself and have no
problems. I package RPM's a fair bit too. I'm not familiar with
recent enhancements, etc.. and I get by so...
>Mike
>Just what's in a src.rpm that's so useful that is NOT in the spec file?
Umm... the source code? Depends on what you mean by "useful" I
suppose. If I want to build "widgetbuilder" program into RPM, I
can get the source tarball and write a .spec for it. Or, I can
get an existing spec, in which case I can download an existing
.src.rpm to get the spec. It would possibly be nice to get the
.spec separately as well, which is what I'm assuming everyone
wants. I don't necessarily have widgetbuilder.rpm installed on
my machine at all anyways so having the .spec in the rpm doesn't
help me. My experience building RPM's is that if you have just
the .spec from something, and not the whole .src.rpm, you can end
up in a mess anyways.
For example, taking pristine source from a website, and obtaining
a .spec from a ready built package. Assuming we ignore the
.src.rpm the spec came from to simulate it being in the
hypothetically installed i386 rpm:
1) We might be able to build a new package from the .spec if it
isn't to difficult a build process and has no patches.
2) Using the .spec, with new source, might find that the .spec
file calls patches you don't have because you don't have the src
rpm. The patches might be required to get the thing to compile
at all, or perhaps are for patching it for RedHat's dir paths,
etc.. Wine is or at least was a good example at one time of
this, and so was licq. Licq was a bastard to package for RPM
because each release changed things drastically. You had to take
the licq source, edit files in it, etc to get it to build
properly at all. So to RPM package it you had to make a set of
diffs and include them with the source, having the .spec patch
the thing from pristine source.
Next release of licq, you took the .spec you'd stashed away, and
tried to use it to build the new package. No go. Put the old
patch files in, still no go. Check out why? Because the build
process changed, and new files are there, old ones gone, stuff
moved, things that the makefile is looking for that aren't there,
etc..
Licq is one example, but there are many others. Granted a lot of
packages you can just take the spec file, change a line at the
top with the new version, plop in the new tarball, and rock and
roll, but with more complex packages, and screwy ones like licq,
it is not the case. Since there is no guarantee of the
usefullness of a given .spec in producing a later version of a
package, the usefulness of installing them with every rpm is
heavily questionable.
I know I won't find a use for spec files for every package on my
system. If I need a spec, I can retrieve the .src rpm and get it
that way, or I can hoof the thing over to meteng and then suck
the .spec out of it and download that. Quite often though, the
.spec doesn't help get the package compiled and needs lots of
modification. The contrib files at redhat are often VERY screwy
too, and useless for a lot of things.
What would be a truely useful solution over all this is an RPM
.spec file RAD tool for X. Run it, click the mouse a few times,
type a few things, click build, and go. THAT would be more
useful IMHO. Donnie Barnes at Red Hat had this as a project plan
about 2 years ago.. I wonder if it ever got started?
Anyone else know of an RPM RAD tool?
--
Mike A. Harris Linux advocate
Computer Consultant GNU advocate
Capslock Consulting Open Source advocate
Try out Red Hat Linux today: http://www.redhat.com
ftp://ftp.redhat.com/pub/redhat/redhat-6.2/
_______________________________________________
Redhat-devel-list mailing list
[EMAIL PROTECTED]
https://listman.redhat.com/mailman/listinfo/redhat-devel-list
