proposal for packaging guidelines: static libraries

[Bill Nottingham]

This seems like it could be useful, considering the discussion of
a couple of days ago:

When to package static libraries
--------------------------------

Often, static libraries are built along with shared objects,
and will be installed by default with 'make install'. However,
there are often cases where it's not practical to ship these
as part of the package.

Some questions to ask before including static libraries in
a package:

1) Are the library's direct dependnecies shipped in static form?

For example, if you are packaging libgnome, you may look at what
libraries are packaged with gtk2. Since gtk2 doesn't ship static
libraries, it doesn't make sense for libgnome to ship them.

2) Is it a build artifact of libtool usage that will never get used?

For example, a package might build a gimp plugin, and have both
.a and .so objects. However, in the presence of the .so objects,
the .a objects will never be used; hence, they shouldn't be shipped.

3) Is it something that would reasonably want to use statically
in a program?

For example, if it's a library that depends on using plugins for
parts of its functionality, it may not make sense. 

-------------- next part --------------
When to package static libraries
--------------------------------

Often, static libraries are built along with shared objects,
and will be installed by default with 'make install'. However,
there are often cases where it's not practical to ship these
as part of the package.

Some questions to ask before including static libraries in
a package:

1) Are the library's direct dependnecies shipped in static form?

For example, if you are packaging libgnome, you may look at what
libraries are packaged with gtk2. Since gtk2 doesn't ship static
libraries, it doesn't make sense for libgnome to ship them.

2) Is it a build artifact of libtool usage that will never get used?

For example, a package might build a gimp plugin, and have both
.a and .so objects. However, in the presence of the .so objects,
the .a objects will never be used; hence, they shouldn't be shipped.

3) Is it something that would reasonably want to use statically
in a program?

For example, if it's a library that depends on using plugins for
parts of its functionality, it may not make sense.