glibc-devel vs. glibc-devel{,-static}

[Ralf Corsepius]

Jakub Jelinek wrote:
> On Wed, Feb 18, 2009 at 08:59:57AM +0100, Ralf Corsepius wrote:
>>> The guidelines say that any package providing static libs needs to Provides: -
>>> static subpackages, and that packages linking with static libs at 
>>> compile time need to BR the -static subpackage, not -devel (even if 
>>> it's the same package). Thus any package not doing this needs to be 
>>> fixed.
>> # rpm -qf /usr/lib/libc.a
>> glibc-devel-2.9-3.i386
>>
>> # rpm -q --provides glibc-devel | grep static
>>
>> <no comment>
> 
> If there is consensus that libc.a doesn't belong into glibc-devel
> and if we are prepared for thousands of bugreports that gcc -static
> stopped working in Fedora 11, sure, libc.a and other static libraries from
> glibc-devel (except lib{c,pthread}_nonshared.a, libbsd{,-compat}.a, libg.a,
> libieee.a, libmcheck.a, librpcsvc.a) can be moved to glibc-devel-static.
Let me put it this way: The *static packaging rule doesn't exist since 
yesterday. It's amongst the oldest rules in the FPG.
Most community maintained packages apply it.


Of course, glibc is special, so I would not want to exclude there might 
be technical constraints why this might not be applicable.


> This would mean among other things that all packages that link with -static
> would automatically fail to build during mass rebuild.
Right, this is what is supposed to happen.

A less radical approach would be to (temporarily) let glibc-devel 
explicitly "Provide: glibc-static" and let everybody who needs to link 
statically against glibc rework his package to
"BuildRequire: glibc-static".

At some later point in time you would physically split *-static from 
*devel, which would then trigger the breakdowns.

I am not sure if a radical or a gradual approach would make more sense.

Ralf