[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