[Fedora-packaging] Static Library Policy Draft Changes

[Patrice Dumas]

On Thu, Apr 10, 2008 at 10:23:54AM +0200, Ralf Corsepius wrote:
> 
> On Thu, 2008-04-10 at 09:50 +0200, Patrice Dumas wrote:
> > On Wed, Apr 09, 2008 at 09:44:36AM -0400, Tom spot Callaway wrote:
> > > 
> > > 2. When a package goes from only providing static libraries to providing
> > > some shared libraries (but not all), we want to be able to track these.
> > 
> > Does it happens?
> This happens all the time.

I don't think so. Currently there are no such packages in fedora, with a
mix of shared and static libs in -devel.

I did the following:
repoquery --whatprovides '*-static' --qf '%{name}' > provides_static_names
for file in `grep -v -- '-static$' provides_static_names`; do repoquery -ql $file | grep '\.so$'; done
/usr/lib/libruby.so
/usr/lib/libfrysk-junit.so
/usr/lib/libnettle.so
/usr/libexec/p7zip/7z.so

I filled a bug against nettle-devel, p7zip and frysk are false positives
(they provides a file ending in -static), so ruby-devel is the only package
doing that sort of thing, but the libraries have different names:
/usr/lib/libruby-static.a
/usr/lib/libruby.so


But maybe you are referring to a package providing only static libraries
then providing shared libraries (in -devel) and static libraries (in
-static). In that case, I think it is not different from the case when a
static library is rebuilt and therefoer the package linking against that
library needs to be rebuilt too. This is covered by the guidelines:

"If you link statically against a library, add yourself to the initialcc
 list for the library so you can watch for any security issues or bug
 fixes for which you'd want to rebuild your package against a new version
 of the library. Here are  instructions for making that request."

In my opinion this also covers going from static to shared, in that case
the maitainer can fill himself a bug when going shared.

> The critical case would be the opposite: A package going from providing
> shared libs to providing static libs only.
> 
> I have never seen this happen, but provides the craziness of some
> upstreams, I would not exclude this to happen.

Indeed, it may happen, but just following the existing guidelines in 
that case seems enough to me.

> * If a library's client package BR:'s *-devel,
> it will pick up the shared library during the next rebuild.
> 
> * If a library's client package BR:'s *-static,
> it will bomb out during the next rebuild.
> 
> 
> The only issue is library-client packages not being automatically
> notified that they might need to be rebuilt. 

As I said above, having the maintainer fill a bug when going shared
should solve this issue, since packagers should already be in CC.

The only issue I see is when a packager doesn't know that he is building
against a static library.

My investigations show that (with ruby excluded), the following -devel
packages consist only of static libs and have dependent packages:

 --> factory-devel
libfac-0:3.0.3-2.fc9.src
Macaulay2-0:1.1-1.fc9.src
 --> flam3-devel
qosmic-0:1.3.1-3.fc9.src
 --> g2clib-devel
ncl-0:5.0.0-10.fc9.src
 --> libassuan-devel
gnupg2-0:2.0.9-1.fc9.src
dirmngr-0:1.0.1-2.fc9.src
 --> libfac-devel
Macaulay2-0:1.1-1.fc9.src
 --> libnet-devel
tcptraceroute-0:1.5-0.5.beta7.fc9.src
dsniff-0:2.4-0.2.b1.fc9.src
etherbat-0:1.0.1-4.fc9.src
libnids-0:1.22-4.fc9.src
heartbeat-0:2.1.3-1.fc9.src
ettercap-0:0.7.3-22.fc9.src
isic-0:0.07-2.fc9.src
intuitively-0:0.7-13.fc9.src
firewalk-0:5.0-2.fc9.src

Also libmimedir-devel and osiv-devel requires the corresponding -static
subpackages since there are no corresponding shared libraries, and
uulib-static provides uulib-devel. This adds:

# repoquery --whatrequires uulib-devel --archlist=src
klibido-0:0.2.5-10.fc9.src
# repoquery --whatrequires uulib-static --archlist=src
nget-0:0.27.1-8.fc9.src
# repoquery --whatrequires libmimedir-devel --archlist=src
librra-0:0.11-2.fc9.src

Also I noticed that some packages BuildRequires static packages, I
filled few bugs, but most of the time, the -devel is also BuildRequires,
and I guess that there is a good reason to BR the static sub package.

--
Pat