.so files in main package for python packages

[Michael Schwendt]

On Sun, 10 Sep 2006 02:41:34 -0700, Christopher Stone wrote:

> Upstream says there is a packaging error in one of my packages,
> pypoker-eval-devel.
> 
> Upstream claims that the .so file should not be in the devel package
> but should be in the main package.
> 
> I told upstream about our .so rule saying .so files should be in
> -devel,

Kindly point to that rule in the Wiki. If it exists, it is wrong and ought
to be reworded.

We do not put all ".so files" into -devel packages.

We put .so symlinks into -devel packages when a system library package
contains the versioned .so.N.M file.

We do that because for normal libraries, in particular system libraries,
the .so symlink/name is only needed at build-time by the linker. "-lfoo"
translates to "link against libfoo.so, following symlinks".

If we didn't, multiple versions of system libraries could not coexist
nicely, because the .so symlinks would conflict. For system libraries, it
is also discouraged to use non-versioned .so symlinks/files for anything
else than linking against them at build-time.

Of course, no such guidelines with exceptions and with the risk of getting
complex and requiring more experience the more complex it gets. There are
valid reasons for a library to be called libfoo.so and to be put into the
main package. For instance, if it's a plugin which is dlopened at run-time,
or a private library outside run-time linker's default search-path. To add
to the complexity, some applications still dlopen system libraries as *.so
instead of *.so.N (expecting the *.so symlinks/files to be present), and
they ought to be patched to open and "Requires" the versioned library in
order to create a proper dependency.