Applications vs. Libraries
It is often not completely obvious whether a particular piece of software should be packaged as an application or as a library. Many packages fall into both categories at the same time. Depending on the programming environment/language used, there may be specific guidelines for packaging of libraries which do not apply to applications, and the presense of executables in a package can cause issues if the package is otherwise intended to be used as a library.
As a general rule, it is left to the packagers to make the choice as they see
fit. It is reasonable for a library package to include executables and still
follow the naming rules for a library/module of the particular programming
language in use. For example, there are perl modules following the usual
perl-example naming which include executables in /usr/bin. They
are primarily intended to be used as Perl modules and are named accordingly.
There are situations where this becomes complicated, however. Python modules may be built for more than one python version, and in this case there are requirements on the names of the executables involved. Compiled code may be architecture-specific, and multilib requirements may require that two different architectures be installed simultaneously, which would cause conflicts between the executables in those packages. In these cases, the packages need to be split.
How to split packages
Naming of split packages
The "application" portion of the package must be named according to the regular naming guidelines for any application. See [NamingGuidelines].
The "library" portion of the package must be named according to the usual library naming rules for the programming language in use. See [Application specific guidelines] (XXX which is horribly named).
When to split packages
In general, if there is a situation such as multilib (in the case of compiled code) or multiple runtime support (in the case of Python), the package must be split to avoid conflicts.
For compiled code, the executables, end user documentation and such would be placed in a package named after the application, say "example" while the libraries and would be placed in a package named "example-libs". (Developer documentation, headers and such would additionally be placed in an "example-devel" package; see [Devel Packages].)
If the main package is a library ("libfoo") that also ships some tools in /usr/bin, those tools should go into a "libfoo-tools" package.
XXX May need a specific sections for "compiled code" mentioning the foo-libs package? How do we even define "compiled code"?
Also, the executables or other non-library portions of a package may have additional dependencies which are not necessary to simply make use of the library portions. In these cases, the packages must (XXX should?) be split.
Provides: for unsplit packages
Even when it is not necessary to split a package, the package should still include Provides: for the libraries included within so that other packages which need to use the library code can access it using the regular dependency mechanisms. In some cases (e.g. Perl libraries or compiled code) RPM itself may generate these. In other cases, they should be provided manually by the packager and must be named according to the usual naming rules for the programming language in use.
Note: be aware of erroneously generated Provides:; see the section on filtering.