[RFC] Braking nfs-utils into -devel and -libs rpms.

[Steve Dickson]

Steve Dickson wrote:
> 
> 
> Peter Jones wrote:
> 
>> On Tue, 2006-01-03 at 19:35 -0500, Steve Dickson wrote:
>>
>>> Enrico Scholz wrote:
>>>
>>>> It everytime a good idea to split libraries and programs when there 
>>>> might
>>>> be other packages using the libs. Else, monolithic packages might/will
>>>> add of unneeded stuff or even dependencies to packages needing the libs
>>>> only.
>>>
>>>
>>> Ok another question... the autoconf files that build the nfs daemons
>>> and commands expect the needed libraries to be already installed
>>> on the build machine. So my question is, when I build things, should
>>> I change the autoconf file so that the build points to the libraries
>>> (and header files) in the build tree or should I require nfs-utils-lib
>>> to be installed on the build machine (i.e. Requires: nfs-utils-lib).
>>>
>>> I guess would guess its the former but I just want to make sure
>>> I'm doing things in the normal or expected way....
>>
>>
>>
>> Definitely the former, or else you'd have to split out the source rpms
>> too, not just the resultant binaries.  And that's almost certainly not
>> the intent.
> 
> The only problems is the top configure.in uses the
> AC_CHECK_LIB() and AC_CHECK_HEADERS() macros to see if
> certain libraries and header files are installed...
> 
> I'm really not sure how to deal with those other than
> commenting them out before the autoconf is done...
Well taking with Nalin, what appears to make the most
sense is to create separate rpms for libnfsidmap.so,
libgssapi.so, librpcsecgss.so which will need to exist
on the build machine. (Note: if I can combine
libgssapi.so and librpcsecgss.so, I will)

The theory is that since they are separate (standalone)
source releases and only I'm breaking up an existing
rpm into an number of smaller rpms there should not
be any push back on getting these new rpms into
both FC and RHEL releases...

If this theory is flawed, please let me know asap...

steved.