.so files in main package for python packages

[Christopher Stone]

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, but he said this is not the case for python packages, and
promptly demonstrated that the libxml2-python package is similar and
that this package puts the .so files in the main pacakge on Fedora as
well.

So is libxml2-python package in error, or is upstream correct and
there are exceptions to the .so rule for python packages?

Upstream informs me that my package will break unless I put the .so
file in the main package.

[Jesse Keating]

On Sunday 10 September 2006 05:43, Christopher Stone wrote:
> 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, but he said this is not the case for python packages, and
> promptly demonstrated that the libxml2-python package is similar and
> that this package puts the .so files in the main pacakge on Fedora as
> well.

Only .so SYMLINKS should be in the -devel package, the symlinks that are made 
to the actual libraries that would be in the main package.  Python modules 
often have unversioned shared object files (.so) that are part of the module.  
They are not development symlinks and they SHOULD be packaged in the main 
package.

[Jesse Keating]

On Sunday 10 September 2006 09:11, Jesse Keating wrote:
> Only .so SYMLINKS should be in the -devel package, the symlinks that are
> made to the actual libraries that would be in the main package.

Whoops, that's not quite right I think...  That's the general idea but I'm 
sure there are exceptions.

[Alexandre Oliva]

On Sep 10, 2006, Jesse Keating  wrote:
> On Sunday 10 September 2006 09:11, Jesse Keating wrote:
> > Only .so SYMLINKS should be in the -devel package, the symlinks that are
> > made to the actual libraries that would be in the main package.
> Whoops, that's not quite right I think...  That's the general idea but I'm 
> sure there are exceptions.

The exception I'm aware of is when the .so name is used for dlopening.