[opensuse-packaging] shlib policy and letters in version
hello, in packaging Python 3.2, i've run into a strange situation regarding the shlib naming policy. Python's shared library is now called "libpython3.2m.so.1.0", "3.2" being python series and "m" a so-called ABI tag. This was part of an upstream attempt to provide a stable ABI for python modules, so we might be stuck with "libpython3.2m" for the next few years. Without the "m", the right name for the library package would be "libpython3_2-1_0". It seems logical that with it, library package would be named "libpython3_2m-1_0". However, the relevant rpmlint check insists the library be called "libpython3_2m1_0". Is this a bug in the rpmlint check, or is there some part of the policy saying that this is how the package should be called? thanks m. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Tue, 18 Jan 2011, Jan Matejek wrote:
hello,
in packaging Python 3.2, i've run into a strange situation regarding the shlib naming policy. Python's shared library is now called "libpython3.2m.so.1.0", "3.2" being python series and "m" a so-called ABI tag. This was part of an upstream attempt to provide a stable ABI for python modules, so we might be stuck with "libpython3.2m" for the next few years.
Without the "m", the right name for the library package would be "libpython3_2-1_0". It seems logical that with it, library package would be named "libpython3_2m-1_0". However, the relevant rpmlint check insists the library be called "libpython3_2m1_0".
Is this a bug in the rpmlint check, or is there some part of the policy saying that this is how the package should be called?
That's what the policy says. Drop the '.so.' but insert a '-' only
if the library name does end with a digit. IIRC.
Richard.
--
Richard Guenther
Hi, On Tue, 18 Jan 2011, Richard Guenther wrote:
in packaging Python 3.2, i've run into a strange situation regarding the shlib naming policy. Python's shared library is now called "libpython3.2m.so.1.0", "3.2" being python series and "m" a so-called ABI tag. This was part of an upstream attempt to provide a stable ABI for python modules, so we might be stuck with "libpython3.2m" for the next few years.
Without the "m", the right name for the library package would be "libpython3_2-1_0". It seems logical that with it, library package would be named "libpython3_2m-1_0". However, the relevant rpmlint check insists the library be called "libpython3_2m1_0".
Is this a bug in the rpmlint check, or is there some part of the policy saying that this is how the package should be called?
That's what the policy says. Drop the '.so.' but insert a '-' only if the library name does end with a digit. IIRC.
Correct. The intention being that you end up with names like "libc6" instead of "libc-6". The above name looks strange because the base version is "1.0" instead of the more usual "1". If the python maintainer go through the trouble of trying to maintain minor levels of shared libs, why don't they correctly differ between major and minor levels? If they would, then SOVERSION of the library would be "libpython3.2m.1", the filename of the major softlink would be "libpython3.2m.so.1", and the package name would be "libpython3.2m1". But they don't the above name is correct. Ciao, Michael. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
participants (3)
-
Jan Matejek -
Michael Matz -
Richard Guenther