Am Dienstag, 18. Januar 2011, 10:45:03 schrieb Richard Guenther:

On Mon, 17 Jan 2011, Cristian Morales Vega wrote:

...

2011/1/17 Christian Trippe <trippe_mailinglisten@gmx.de>:

...

/usr/lib/libgetdatabzip2-0.7.1.so /usr/lib/libgetdatabzip2.so /usr/lib/libgetdatagzip-0.7.1.so /usr/lib/libgetdatagzip.so /usr/lib/libgetdatalzma-0.7.1.so /usr/lib/libgetdatalzma.so

AFAIU these are unversioned, so packaging them separatly does not make much

...

sense. However rpmlint still complains: It seems the libraries change the soname with every release. But that doesn't means users couldn't want to install two versions at the same time. Using the SLPP is still the correct thing to do, the name of the package comes from https://build.opensuse.org/package/view_file?file=LibraryPolicyCheck.py& package=rpmlint&project=openSUSE:Factory:

def libname_from_soname (soname): libname = string.split(soname, '.so.')

if len(libname) == 2: if libname[0][-1:].isdigit(): libname = string.join(libname, '-')

else: libname = string.join(libname, '')

else: libname = soname[:-3]

libname = libname.replace('.', '_') return libname

So "libgetdatabzip2-0.7.1.so" should be in the "libgetdatabzip2-0_7_1" package.

Indeed. If the libraries are tightly bound to a single user (program) then they should reside in /usr/lib/$program/ instead and be packaged in the same package as the binary referring to them.

They are not bound to a specific program. So i went with what Cristian suggested. However now I get: libgetdatagzip-0_7_1.x86_64: W: shlib-unversioned-lib libgetdatagzip-0.7.1.so libgetdatalzma-0_7_1.x86_64: W: shlib-unversioned-lib libgetdatalzma-0.7.1.so libgetdatabzip2-0_7_1.x86_64: W: shlib-unversioned-lib  libgetdatabzip2-0.7.1.so Your package matches the Shared Library Policy Naming Scheme but contains an unversioned library. Therefore it is very unlikely that your package can be installed in parallel to another version of this library package. Consider moving unversioned parts into a runtime package. libgetdatagzip-0_7_1.x86_64: W: shlib-policy-missing-lib libgetdatalzma-0_7_1.x86_64: W: shlib-policy-missing-lib libgetdatabzip2-0_7_1.x86_64: W: shlib-policy-missing-lib Your package starts with 'lib' as part of it's name, but does not provide any libraries. It must not be called a lib-package then. Give it a more sensible name. Especially the second error sounds strange to me, as there is of course a library in each package. Thanks for the help. Christian -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

2011/1/18 Philipp Thomas <Philipp.Thomas2@gmx.net>:

I'd file a bug against rpmlint and request that the package be added to the whitelist.

If it's done, the problem seems to be the last line from # Check for non-versioned libs in a std lib package if std_lib_package: for lib in libs.copy(): if not lib[-1].isdigit(): printWarning(pkg, "shlib-unversioned-lib", lib) libs.remove(lib) A comment explaining why libs detected as unversioned aren't considered as libs at all would not hurt... supposing it makes any sense to start with. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

On Tue, 18 Jan 2011, Cristian Morales Vega wrote:

2011/1/18 Christian Trippe <trippe_mailinglisten@gmx.de>:

...

libgetdatagzip-0_7_1.x86_64: W: shlib-unversioned-lib libgetdatagzip-0.7.1.so  libgetdatalzma-0_7_1.x86_64: W: shlib-unversioned-lib libgetdatalzma-0.7.1.so  libgetdatabzip2-0_7_1.x86_64: W: shlib-unversioned-lib libgetdatabzip2-0.7.1.so  Your package matches the Shared Library Policy Naming Scheme but contains an  unversioned library. Therefore it is very unlikely that your package can be  installed in parallel to another version of this library package. Consider  moving unversioned parts into a runtime package.

 libgetdatagzip-0_7_1.x86_64: W: shlib-policy-missing-lib  libgetdatalzma-0_7_1.x86_64: W: shlib-policy-missing-lib  libgetdatabzip2-0_7_1.x86_64: W: shlib-policy-missing-lib  Your package starts with 'lib' as part of it's name, but does not provide any  libraries. It must not be called a lib-package then. Give it a more sensible  name.

Especially the second error sounds strange to me, as there is of course a library in each package.

The first one can be ignored. It's understandable why it says so, but you know that "it is very *likely* that your package can be installed in parallel to another version of this library package" since the library name itself will change (to libgetdatagzip-0.7.2.so or libgetdatagzip-0.8.0.so).

Yes - the check can't know this.

The second one IMHO is an error in the rpmlint check. But I don't know the history, the "broken" part perhaps fixes something else. The thing is that if all the libraries in a package show the "shlib-unversioned-lib" warning then the "shlib-policy-missing-lib" will also be shown. Since you have a single library and is detected as unversioned...

The check is supposed to catch the .so symlink that belongs into a -devel package (and doesn't count as a shlib) vs. a (versioned) shared library which always has a version after .so. In fact an unversioned library is both the devel and the shlib part. One could restrict the check so that non-symlink .so files are allowed, but unfortunately that would bogously trigger for linker-script .so files as well, so it will be not that simple to avoid the warning for your case (and it is indeed useful in general, so dropping it isn't an option either).

But since I had to look into your package... There is something that seems to be really wrong. I didn't verify, but I would say the only real library is the one from "libgetdata4". It looks like "libgetdatabzip2-0_7_1", "libgetdatagzip-0_7_1" and "libgetdatalzma-0_7_1" aren't real libraries but just plugins for "libgetdata4". In such a case those plugins should be installed inside its own dir (e.g. /usr/lib64/getdata071), and the package name doesn't needs to follow SLPP anymore.

Indeed. Those could also go in the libgetdata4 package itself.

To change this you probably will need to touch the source code. And the patch should be submitted upstream. All this, again, supposing libgetdataXXX are just plugins. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

-- Richard Guenther <rguenther@suse.de> Novell / SUSE Labs SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746 - GF: Markus Rex