On Mon, 2007-05-21 at 20:47 -0700, Toshio Kuratomi wrote:

I've written a draft of changes to the static library guidelines:: http://fedoraproject.org/wiki/PackagingDrafts/StaticLibraryChanges

There are three pieces which can be voted on separately or together depending on how controversial they are:

1. Separate static library inclusion from static library linkage and

make static library inclusion less strict. 2) Change how to package static libraries when the package does not include dynamic libraries (per Ralf's note to the list) 3) Incorporate mschwendt's note about *.la files directly into the guidelines instead of as a footnote.

Comments welcome.

+1 +1 +1

One comment interspersed below, also I'd like so see another addition:

"Development libraries" (libraries not being used at runtime) must not be packaged in /%{_lib}.

If a package needs "runtime libs in /%{_lib} (Normally lib*.so.* being used by applications which shall be run at times when /usr might not be available, typically apps being used at bootup), the corresponding development libraries (Normally: lib*.so and *.a) should be packaged into %{_libdir}

== Exclusion of Static Libraries == Packages including libraries should exclude static libs as far as possible (eg by configuring with ''--disable-static''). Static libraries should only be included in exceptional circumstances. Applications linking against libraries should as far as possible link against shared libraries not static versions.

Libtool archives, ''foo.la'' files, should not be included. Packages using libtool will install these by default even if you configure with ''--disable-static'', so they may need to be removed before packaging. Due to bugs in older versions of libtool or bugs in programs that use it, there are times when it is not always possible to remove *.la files without modifying the program. In most cases it is fairly easy to work with upstream to fix these issues.

If a Fedora release had been shipped with lib*.la's they must not be removed during this Fedora release's life-time.

=== Packaging Static Libraries ===

• In general, packagers are strongly encouraged not to ship static libs

unless a compelling reason exists.

• We want to be able to track which packages are using static libraries

(so we can find which packages need to be rebuilt if a security flaw in a static library is fixed, for instance.)

• When a package provides both dynamic and static libraries the static

libraries must be placed in a ''*-static'' subpackage. Separating the static libs from the other development files in ''*-devel'' allow us to track this usage by checking which packages Build''''''Require the ''*-static'' package.

• When a package only provides static libraries you can place all the

files in the ''*-devel'' subpackage. When doing this you also have to have a virtual Provide for the static package: {{{ %package devel Provides: foo-static = %{version}-%{release} }}} This way other packages which will link against a dynamic library when your package starts providing one can {{{BuildRequire: foo-devel}}} and packages which explicitly need to link against the static version can {{{BuildRequire: foo-static}}}

=== Staticly Linking Executables ===

• Static linkage is a special exception and should be decided on a

case-by-case basis. The packager must provide rationale for linking statically, including precedences where available, to FESCO for approval.

Ralf

On Mon, May 21, 2007 at 08:47:56PM -0700, Toshio Kuratomi wrote:

== Exclusion of Static Libraries == Applications linking against libraries should as far as possible link against shared libraries not static versions.

I think it could be even stricter, like When there are shared and static libraries, applications should link against shared libraries except for exceptionnal circumstances, like dynamically linked applications being non-functionnal.

I am perfectly happy with this draft. I will try to work on a paragraph trying to explain the case of numerical libs/portability and so on to provide guidance on this kind of 'exceptionnal circumstances'.

-- Pat