[bt-devel] Mandrake, kde3, spec's, and rpm's.

[Lamar Owen]

On Sunday 26 May 2002 11:15 am, Brook Humphrey wrote:
> So any one that would like to help with the spec files please speak up. I
> know there was at least one other person who worked with the postgres
> people making rpm's that expressed a desire to help.

Yes.  Sorry for the delay.  I have been *swamped* here lately.

First, like I said earlier, I don't want to step on anyone's toes while trying 
to help. :-)  Having said that, I'm interested in seeing what you would like 
for me to work on.

I would like to see more automation in the spec file in terms of picking the 
target distribution.  From what I understand of the process as it currently 
exists, the configure script can write out a spec file tailored to the dist 
upon which configure was run.  This seems at first blush to be a very good 
thing.

And it is a very good thing -- until the day some linux distributor picks up 
Bibletime for their distribution.  I can only speak of Red Hat's build policy 
and techinques, but I'm pretty sure other distros use similar set ups.

Red Hat has a build farm for nothing but rebuilding RPMs.  Those RPM's need to 
be completely rebuildable by using 'rpm --rebuild foo.src.rpm' and nothing 
else.

So, unless someone objects, my goal would be to get intelligence in the spec 
file to fathom what distro we're building on and set the various values 
accordingly.  Things such as %prefix and the OS version.  The Mandrake menus 
and a SuSEConfig script (if needed) should be determined entirely within the 
spec file.  As an RPM packager, I'm used to a simple 'rpm --rebuild' to get 
fresh binary RPMs from whatever package I need -- in fact, I install very 
little from prepackaged binary RPMS -- I almost always --rebuild them myself.  
Bibletime requires me to perform more work to rebuild currently.  I had been 
hand editing the spec file -- I didn't know about the configure trick.  I 
haven't yet had time to try it yet, unfortunately.

Next, I would want to see about the feasibility of dynamic linking sword and 
emitting a Requires: for sword of a particular version.  I haven't dug deep 
enough yet to see the reasons that it is the way it currently is set up -- I 
might very well be full of hot air! :-)  But I know a linux distributor such 
as Red Hat would require this.

RPMs for each SWORD module don't fall under this list, but those would be very 
useful, IMO.

Since you've already split the documentation into a separate tarball, 
subpackaging the docs isn't needed.  

Bibletime is a pretty straightforward package to, uh, _package_.  I'm just 
trying to understand why the spec file is structured the way it is -- as I'm 
sure there is a rational reason why it is the way it is.

Brook, barring automatic configuration of some of those values, I have found 
that conditional defines work well:
%{?!prefix:%define prefix /opt/kde}
does this: 'If prefix is not already defined, then define prefix to be 
/opt/kde'.  What this allows is command line defines:
rpm --define 'prefix /usr' --rebuild bibletime.src.rpm
to rebuild with a different prefix.  This sort of thing is not nearly as 
optimal as automatic configuration, though.

But I'm still interested in the rationale for the existing spec file.

God bless.
-- 
Lamar Owen
WGCR Internet Radio
1 Peter 4:11