[lug] another fedora rpm build question
D. Stimits
stimits at comcast.net
Fri Jul 15 19:00:52 MDT 2005
...
>
> You either want to list these in a %files section for one of the
> binary RPMs you are generating, or you want to:
>
> %define _unpackaged_files_terminate_build 0
Ok, thanks for that tip! I guess I won't go bald quite as fast now :)
I'm running into yet another question now though. Each time I get one
step further, it doubles the number of questions I have.
I was able to achieve creation of the binary rpm for the i386 of this
dynamic library. It also (pleasantly surprising) created the debuginfo
library (I'm guessing it does this through the strip process).
My next stumbling block is in getting a devel version of the package.
The base install consists of the lib file, and perhaps some simple docs.
The devel package should consist of one header file, and perhaps a man
page for the API to the library. Looking at some other spec files, and
going by things people have revealed on occasion, it seems that most
(but not all) of the spec file directives starting with percent, e.g.,
%package, can take optional arguments. For example, there is a
"%description" section, as well as a "%description devel", or "%files"
and "%files devel".
Well, I guess I took that theme too far. I'm trying to create a devel
package, and having created too many duplicates of other sections with
the argument "devel", it is once again broken. The odd thing though is
the error is about the debuginfo, which I did not even add...this
section seems automated and triggered by the stripping:
error: Package already exists: %package debuginfo
What I think is happening is that "%install" can't be overloaded, and
that my section "%install devel" is breaking it. What is the proper way
to specify a development package that consists only of a header file? I
wish I had a list of the "%" directives...something like an XML DTD, as
I feel I'm just making too many guesses as to what a directive accepts,
what can go in it, what must go in it, so on.
D. Stimits, stimits AT comcast DOT net
More information about the LUG
mailing list