Mailinglist Archive: opensuse-packaging (162 mails)

[Dave Plater <dplater@xxxxxxxxxxxxxxxx>]

On 02/14/2010 08:23 PM, David Haller wrote:
> Hello,
>
> On Sun, 14 Feb 2010, Michael Matz wrote:
> [..]
>   
> > Hence, you need to determine this before.  If they turn out to be plugins, 
> > you simply need to package them into a non-libdir directory private to 
> > COLLADA (and need to make the changes in there to make it find those 
> > plugins in that directory).
> >     
> I agree. Iff they're libraries though, and the 'lib-' prefix suggests
> that[1], I'd suggest static linking. If they're plugins, they should be
> included in the main or a -plugin package, and for an SONAME it seems
> to be common to use just 'foo.so' for the plugin foo.so. To use 'lib-'
> prefixes or versioned sonames for plugins is a bit uncommon.
>
>   
> > In that case you also don't need to add 
> > version suffixes.  A SONAME still would be good to have but isn't that 
> > terribly necessary either anymore.
> >     
> Aye. For Dave: you can set the SONAME to "libfoo.so.N" by passing
>
>     -soname libfoo.so.N
>
> to the linker ('ld') which you can do via gcc by using
>
>     -Wl,-soname,libfoo.so.N
>   
Thanks, I will try that option, I'm still fighting with the SConscript
option passing, I have a patch for that. I also need to get scons to
accept options passed from the spec file, I think it's "import os" but
I've yet to test it.
> or the equivalent
>
>     -Wl,-soname -Wl,libfoo.so.N
>
> (or '-Wl,-soname,foo.so' for a plugin)
>   
Collada is definitely not a plugin, blender had a collada plugin a few
years ago, it's an integrated part of the blender sources that needs to
build against the openCOLLADA libraries.
> on the commandline creating the .so (i.e. the 'gcc .. -shared ..'
> call). Depending on the buildsystem, it can be quite a pain to
> 'insert' that. *sigh*
>
> BTW: the SONAME is what rpm will also pick up as a dependency and
> provide (per default), possibly garnished with arch-stuff.
>   
Rpm picks up the sonames I created with:-
"find *.so -exec mv -v {} {}.0.0.0 \; -exec ln -s {}.0.0.0 {} \; -exec
ln -s {}.0.0.0 {}.0 \;" and puts the correct dependencies in blender but
I wasn't aware of the SONAME lable in the binary which I imagine is for
ldconfig or not?
> HTH,
> -dnh
>
> [1] OTOH, I see no reason why plugins shouldn't have versions and a
>     lib-prefix. It's just not commonly used / a convention, but I
>     don't actually see where it'd do harm (other than suggest it's a
>     generally useable lib). I think, much of it depends on the naming
>     scheme. And actually, xmms uses lib- prefixes for it's plugins
>     (e.g. ${prefix}/lib/xmms/Output/libdisk_writer.so). If plugins
>     were named like lib${APP}[-_]?plugin[-_]${FUNCTION}.so[.${VERSION}], I
>     don't think there'd be confusions about lib/plugin, e.g.:
>         ${prefix}/lib/xmms/Output/libxmmsplugin_disk_writer.so.0
>     would be as easily identifiable as a plugin as the current
>     plugin. Or as another example consider:
>         ${prefix}/lib/mplayer/vidix/nvidia_vid.so
>     vs.
>         ${prefix}/lib/mplayer/vidix/libmplayerplugin_vidix_nvidia_vid.so.0
>     or
>         ${prefix}/lib/mplayer/vidix/libmplayerplugin_vidix_nvidia.so.0
>     or whatever.
>   
Blender has a number of plugins that reside under %_libdir/%name/ and
they neither have a version number nor a lib prefix, this was already
there when I took over as maintainer and from what I read in
Shared_Library_Packaging_Policy is acceptable.
Thanks
Dave P
-- 
To unsubscribe, e-mail: opensuse-packaging+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-packaging+help@xxxxxxxxxxxx