static libraries/devel subpackages

[Ville Skyttä]

On Mon, 2005-08-22 at 15:51 +0200, Patrice Dumas wrote:

> 1) In the packaging guidelines there is a paragraph about
>   Exclusion of Static Libraries
> with is the following sentence:
> "Static libraries should only be included in exceptional circumstances"
> 
> Should it really be followed? I may be wrong but all the packages I know 
> in extra distribute the static libraries in -devel subpackages.

The guideline is newer than most packages in Extras, and nowhere near
all packages have been adopted yet, but some have.

IMO, dropping the static libs from an existing package should be done
only between distros, not during the package's life cycle between
package release bumps for example in FC-4.  The people likely being
bitten by this (if anyone) are almost certainly 3rd parties as the
static libs are very rarely being used within Extras -> we can't know
exactly what are the consequences so better not inflict it on anyone
within one distro version.

> 2) It also seems to me that something about the devel subpackages is missing
> in the packaging guidelines. More precisely I think that the following
> should be stated:
> 
> * When should a devel package be done (I believe always if possible)

Whenever it makes sense.  It depends.  It's possible to make a -devel
subpackage for let's say one *.so symlink and one *.h, but hardly worth
it.  Better to have "Provides: %{name}-devel = %{version}-%{release}" in
the main package instead and require that provided -devel in dependent
packages (if any) in preparation for the future.

> * what to put in -devel and non-devel package (in devel include files static
>   libs, api documentation, .so file, lib-config utility, code samples)
>   rpmlint does a good work at detecting some of these items.

+ pkgconfig files, m4 files, binaries relevant only to -devel in
general... it's hard to provide an exhaustive list.

> * it should be noted that the -devel package should require the non devel
>   package and how it should do so: 
>     - with
> Requires:       %{name} = %{version}-%{release}
>     - or
> Requires:       %{name} = %{version}

The former is safer; the build options may vary between release bumps,
the build environment may change slightly due to new versions of
dependencies installed etc.  This may result in API/ABI
incompatibilities even if the sources don't change, and it's important
to keep the main and -devel in sync.