Re: [opensuse-packaging] error: Your package contains a single shared library but is not named after its SONAME.
2010/7/28 Greg KH
I'm trying to package up the liboauth library (needed for my bti tool as twitter is about to require oauth authentication soon) and I'm getting the following error from rpmlint:
liboauth.i586: E: shlib-policy-name-error (Badness: 10000) liboauth0 Your package contains a single shared library but is not named after its SONAME.
My .spec file seems sane and simple, yet I can't figure out the real issue here. Odds are it's a problem in the original package, as I can't see any other distro packaging it yet and it's very new.
My package is at: https://build.opensuse.org/package/show?package=liboauth&project=home%3Agregkh
if anyone wants to take a look at it and tell me how badly I messed it up :)
And yes, I did read the information at: http://en.opensuse.org/openSUSE:Shared_library_packaging_policy but can't find anything relevant to this issue there, but I might be totally missing the relevant portion.
Any help is greatly appreciated.
Since the soname of the library is liboauth.so.0 the package that contain it must be named liboauth0, but your package is named liboauth (lacks the 0 at the end). You just need to rename it. Note that the devel package must be named liboauth-devel, not liboauth0-devel. So you can't do "%package devel", instead you will need "%package -n liboauth-devel". -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Wed, Jul 28, 2010 at 09:44:43PM +0200, Cristian Morales Vega wrote:
2010/7/28 Greg KH
: I'm trying to package up the liboauth library (needed for my bti tool as twitter is about to require oauth authentication soon) and I'm getting the following error from rpmlint:
liboauth.i586: E: shlib-policy-name-error (Badness: 10000) liboauth0 Your package contains a single shared library but is not named after its SONAME.
My .spec file seems sane and simple, yet I can't figure out the real issue here. Odds are it's a problem in the original package, as I can't see any other distro packaging it yet and it's very new.
My package is at: https://build.opensuse.org/package/show?package=liboauth&project=home%3Agregkh
if anyone wants to take a look at it and tell me how badly I messed it up :)
And yes, I did read the information at: http://en.opensuse.org/openSUSE:Shared_library_packaging_policy but can't find anything relevant to this issue there, but I might be totally missing the relevant portion.
Any help is greatly appreciated.
Since the soname of the library is liboauth.so.0 the package that contain it must be named liboauth0, but your package is named liboauth (lacks the 0 at the end). You just need to rename it.
Ah, thanks, that makes a bit more sense, but not entirely, why don't all libraries have the N at the end of their package names?
Note that the devel package must be named liboauth-devel, not liboauth0-devel. So you can't do "%package devel", instead you will need "%package -n liboauth-devel".
Thanks, that makes sense. greg k-h -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
El 28/07/10 16:23, Greg KH escribió:
Ah, thanks, that makes a bit more sense, but not entirely, why don't all libraries have the N at the end of their package names?
Because not all libraries have been adapted to the policy yet. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Wed, Jul 28, 2010 at 04:27:15PM -0400, Cristian Rodríguez wrote:
El 28/07/10 16:23, Greg KH escribió:
Ah, thanks, that makes a bit more sense, but not entirely, why don't all libraries have the N at the end of their package names?
Because not all libraries have been adapted to the policy yet.
Then how are they building properly in obs? thanks, greg k-h -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
El 28/07/10 16:59, Greg KH escribió:
Then how are they building properly in obs?
They are whitelisted. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Wed, Jul 28, 2010 at 05:07:52PM -0400, Cristian Rodríguez wrote:
El 28/07/10 16:59, Greg KH escribió:
Then how are they building properly in obs?
They are whitelisted.
Ah, ok, that makes sense why trying to look at a package that was building today was not causing those errors. Fun stuff, greg k-h -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
2010/7/28 Cristian Rodríguez
El 28/07/10 16:59, Greg KH escribió:
Then how are they building properly in obs?
They are whitelisted.
Or they trigger different problems that happen to be warnings instead of errors... - libpt2: libpt2.x86_64: W: shlib-unversioned-lib libpt2.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. - opal: opal.x86_64: W: shlib-policy-missing-suffix Your package containing shared libraries does not end in a digit and should probably be split. (I already fixed these two, I will submit them when bnc#626455 is fixed so Ekiga compiles and I can verify my changes don't break it) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On 2010-07-28 21:44:43 +0200, Cristian Morales Vega wrote:
Since the soname of the library is liboauth.so.0 the package that contain it must be named liboauth0, but your package is named liboauth (lacks the 0 at the end). You just need to rename it.
WRONG solution. right solution: liboauth.spec Name: liboauth ... %define libname liboauth0 %package -n %{libname} ... %package devel Requires: %{libname} = %{version} ... no %files section for main package so it wont get created. that way you dont have to rename the spec file/main package on every soversion bump. see my submitrequest. darix -- openSUSE - SUSE Linux is my linux openSUSE is good for you www.opensuse.org -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
2010/7/28 Marcus Rueckert
that way you dont have to rename the spec file/main package on every soversion bump.
No real need to name the spec file as
On 2010-07-28 22:43:03 +0200, Cristian Morales Vega wrote:
but who cares? ;-)
everyone, who wants to get a package into distro. especially why use a crappy solution when you got a nice and easy one aswell? darix -- openSUSE - SUSE Linux is my linux openSUSE is good for you www.opensuse.org -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
2010/7/28 Marcus Rueckert
On 2010-07-28 22:43:03 +0200, Cristian Morales Vega wrote:
but who cares? ;-)
everyone, who wants to get a package into distro.
especially why use a crappy solution when you got a nice and easy one aswell?
Crappy? The only problem is that you get a warning saying "Your spec filename must end with '.spec'. If it's not the case...". And it *is* the case, the filename ends with '.spec'. So a false warning is the only problem. Your solution isn't free of problems. If there are two versions of a library with different sonames (and that case is the cause we have a SLPP), both will create "-debugsource" packages with the exact same name. Anyway, I don't want to win the "best solution award" here. But please, don't reject SRs because of this IMHO matter of taste... -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On 2010-07-29 00:27:46 +0200, Cristian Morales Vega wrote:
Anyway, I don't want to win the "best solution award" here. But please, don't reject SRs because of this IMHO matter of taste...
nothing to do with taste. the policy says spec name and Name: have to match. darix -- openSUSE - SUSE Linux is my linux openSUSE is good for you www.opensuse.org -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Thu, 29 Jul 2010, Marcus Rueckert wrote:
On 2010-07-29 00:27:46 +0200, Cristian Morales Vega wrote:
Anyway, I don't want to win the "best solution award" here. But please, don't reject SRs because of this IMHO matter of taste...
nothing to do with taste. the policy says spec name and Name: have to match.
darix
Then, please, for all what's holy: Put this info as error message. E.G.: Warning mismatch of spec-filename and Project "Name:"-field. As it is it's misleading and deceptive. And not to mention undocumented outside of the Policy-checking code itself (Wiki? - search with error-message gives nothing.) Thanks for clearing this issue, cheers, Michael. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Thu, Jul 29, 2010 at 02:00:32AM +0200, Michael Foerster wrote:
Then, please, for all what's holy: Put this info as error message. E.G.: Warning mismatch of spec-filename and Project "Name:"-field.
osc rq show -d 44159
As it is it's misleading and deceptive. And not to mention undocumented outside of the Policy-checking code itself (Wiki? - search with error-message gives nothing.)
http://en.opensuse.org/openSUSE:Packaging_checks#invalid-spec-name Petr -- Petr Uzel IRC: ptr_uzl @ freenode
2010/7/29 Marcus Rueckert
On 2010-07-29 00:27:46 +0200, Cristian Morales Vega wrote:
Anyway, I don't want to win the "best solution award" here. But please, don't reject SRs because of this IMHO matter of taste...
nothing to do with taste. the policy says spec name and Name: have to match.
Where? An important thing the SLPP says is "The main rationale is to allow for two (incompatible) versions of a shared library packaged as libfoo1 and libfoo2 installed at the same time without causing RPM conflicts" And since your solution doesn't allows two -debugsource packages of (incompatible) versions of a shared library it violates that *main* rationale. Anyway, if you are going to reject SRs because of this it's OK with me.... IFF you patch rpmlint and convert that warning in an error. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
participants (6)
-
Cristian Morales Vega
-
Cristian Rodríguez
-
Greg KH
-
Marcus Rueckert
-
Michael Foerster
-
Petr Uzel