[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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



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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]