2010/2/14 Dave Plater
On 02/14/2010 10:51 AM, Cristian Morales Vega wrote:
2010/2/14 Dave Plater
: Hi, the next generation of the package I maintain, blender has a new feature called collada which enables 3D import and export similar to cad's dxf file format. In order to enable this feature I've had to incorporate a package called openCOLLADA into blender and the build of the package produces several libraries named :- libbuffer.so libftoa.so libGeneratedSaxParser.so libMathMLSolver.so libOpenCOLLADABaseUtils.so libOpenCOLLADAFramework.so libOpenCOLLADASaxFrameworkLoader.so libOpenCOLLADAStreamWriter.so libUTF.so Which following the "Shared_Library_Packaging_Policy" guidlines, I've added a 0.0.0 suffix with symbolic links containing plain .so and .so.0.
The "Shared_Library_Packaging_Policy" guidlines say: "SONAME - the name (query for it using objdump -x libfoo.so.1 | grep SONAME)". "0.0.0" is really the output you get from objdump or you just used that because nothing else was available?
objdump -x doesn't give any output containing upper or lowercase soname for any of the generated libs. The libs build with an .so extension only, I had to add the 0.0.0 suffix and create the links myself. This package is a work in progress package from GOC and they state that the shared lib build is untested, in the output from scons -h, but blender devels have tested it and are happy that it works. I had to patch a few SConscripts and SConstruct to get it to build properly with openSUSE expat and pcre.
I'm getting several rpmlint warning which would indicate to me that I've done something wrong, "W: no-soname" for each lib and
Either these files aren't libraries but plugins (shouldn't be in /usr/lib and should be packaged in the main blender package or blender-plugins) or openCOLLADA doesn't follows any versioning scheme. If the latter, either you worry about maintaining an openSUSE-specific soname, or it's better to use the static versions of these libraries.
The "Shared_Library_Packaging_Policy" only makes sense if the libraries maintain sonames that make sense (change every time the binary compatibility is broken).
They are definitely libraries needed for blender-2.50 with Collada import/export to build against and there are sure to be more packages that use them in the future. They should be packaged separately once the package is more mature as it also contains other 3D graphics rendering programs. At the moment I have to create the tarball from svn as there isn't a release yet, I'm just getting the next generation blender in order in advance. It will most probably be another month before blender-2.5 is released. So what to do, fix the versioning and soname generation in openCOLLADA or is there a way for me to package it successfully as it is without altering it?
It is not just getting it to work, it is to make a promise for the future. If now you package it as libopenCOLLADA0 every new package with that name must be binary compatible with the old version. But you are not under control about that, upstream devs are the ones that decide if they want to break the compatibility. Looking at the openCOLLADA website it seems they release 3DS Max/Maya plugins. The libOpenCOLLADABaseUtils.so and other libraries look like internal libraries to them, not something they think to release. So, what you need is to contact openCOLLADA devs and know what their plans are: - If they plan to release shared versions of these libs with a sane versioning scheme great. Meanwhile you can use the static versions. Or, if you think more packages will use this library before upstream releases an official version, use a soname that you know they will never use in the future (libOpenCOLLADABaseUtils.so.pre0a?) - If they have no plans to release shared versions bad luck. Perhaps they change the API too frequently and you will never get two packages able to compile with the same version. If so just use the static libs. Otherwise you can think about using your own sonames, but isn't something I would like to do in the long term... Perhaps you could talk with other distro packagers to make it easier and try to maintain some cross-distro compatibility. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org