[opensuse-factory] Package naming conventions

older
[opensuse-factory] New Tumbleweed...

Roger Oberholtzer

27 Oct 2017 27 Oct '17

09:18

I am cleaning up my home project on OBS, removing things that are now in a mainstream package or otherwise not needed. One thing I use OBS for is making Windows versions of various packages. Part of my cleanup is to remove any things that I have that are now duplicates. When all is cleaned up, I hope to suggest that some packages move to the official projects. In doing this, I want to try to maintain compatible names wherever possible. This is not always obvious. Mainly because the naming convention in OBS is sometimes less than obvious. Let me use an example: proj - which does geographic projections. There is no Windows version (except in my project). I want to name the project as close to the Linux name so that it is obvious that it is the same package proj exists in two places (at least): https://build.opensuse.org/package/show/Application%3AGeo/proj where it is called libproj12 (from source proj4.9.3) https://build.opensuse.org/package/show/openSUSE%3ALeap%3A42.3/proj where is is called libproj9 (from source proj4.9.2) The use of 9 or 12 in the name has nothing at all to do with the proj source. It is, I think, a rather arbitrary number assigned to the name by the packager in OBS. There is no property in proj to which it refers. proj is not the only package that does this. Why is this done? So many other packages have different versions available, and they do not resort to adding a strange number to the name to differentiate them. And what is even more obtuse is that the libraries are named with these numbers that have nothing at all to do with the package: /usr/lib64//libproj.so -> libproj.so.12.0.0 /usr/lib64//libproj.so.12 -> libproj.so.12.0.0 /usr/lib64//libproj.so.12.0.0 If one wanted to have a library for each proj release, why wouldn't they be called libproj.so.4.9.3? That is, after all, where this version of the library came from. And, if one wants to do as I am doing - making a package that is a port to Windows - how should the items be named? Should I just select another apparently random number? I suspect not. But perpetuating the oddness of assigning a unrelated number to the package name seems just as incorrect. I only used proj as an example. This is done all over OBS. I have read the docs on naming, and I do not feel that this aspect is described. At least not so I recognized it. -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Show replies by date

Dominique Leuenberger / DimStar

27 Oct 27 Oct

09:26

On Fri, 2017-10-27 at 11:18 +0200, Roger Oberholtzer wrote:

...

https://build.opensuse.org/package/show/Application%3AGeo/proj where it is called libproj12 (from source proj4.9.3)

https://build.opensuse.org/package/show/openSUSE%3ALeap%3A42.3/proj where is is called libproj9 (from source proj4.9.2)

The use of 9 or 12 in the name has nothing at all to do with the proj source. It is, I think, a rather arbitrary number assigned to the name by the packager in OBS. There is no property in proj to which it refers.

The 9 and 12 refers to the ABI version of the library provided and matches the filename libproj.so.9 resp libproj.so.12 - and as such DOES come from the proj sources

...

Why is this done? So many other packages have different versions available, and they do not resort to adding a strange number to the name to differentiate them.

This is part of the shared library packaging policy - it's main purpose is to have binaries built against different versions of the library being able to co-exist

...

And what is even more obtuse is that the libraries are named with these numbers that have nothing at all to do with the package:

/usr/lib64//libproj.so -> libproj.so.12.0.0 /usr/lib64//libproj.so.12 -> libproj.so.12.0.0 /usr/lib64//libproj.so.12.0.0

These numbers are as well defined by proj's buildsystem, namely by the library version assigned. No openSUSE invention here

...

If one wanted to have a library for each proj release, why wouldn't they be called libproj.so.4.9.3? That is, after all, where this version of the library came from.

Try to read up on 'library versioning' - that should explain things (maybe... many upstreams also don't get it :P )

...

And, if one wants to do as I am doing - making a package that is a port to Windows - how should the items be named? Should I just select another apparently random number? I suspect not. But perpetuating the oddness of assigning a unrelated number to the package name seems just as incorrect.

As explained above, nothing random - For windows though, the concept of parallel installable shared libraries is a bit moot as the files are .just. called .dll; so multiple versions can't co-exist, unless the version is encoded in the actual part of the filename. Cheers Dominique PS: this does not sound like a -factory topic; it is definitively not related to the development of Leap or Tumbleweed - nevertheless an interesting question

Roger Oberholtzer

09:55

On Fri, Oct 27, 2017 at 11:26 AM, Dominique Leuenberger / DimStar wrote:

...

PS: this does not sound like a -factory topic; it is definitively not related to the development of Leap or Tumbleweed - nevertheless an interesting question

I wasn't sure where to post this. So I tried here. I am going to follow up on the ABI version number stuff in proj. I do know that is how this works. I am a software developer. I am checking with the proj people to see how they are tracking the ABI compatibility. For as long as I have used proj, I do not recall seeing this number reported. Since I link against -lproj, my Makefiles just reference the current development RPM that is installed. I didn't mention that there is also a libproj0 on OBS. I don't think that is ABI version 0. Maybe it is before proj defined ABI version numbers... Perhaps one should use a label like ABIversion in the spec file. Then it is more obvious that this is where the number is from. There is no guarantee that everyone setting this number is doing so for the same reason. -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Dominique Leuenberger / DimStar

10:00

On Fri, 2017-10-27 at 11:55 +0200, Roger Oberholtzer wrote:

...

I am going to follow up on the ABI version number stuff in proj. I do know that is how this works. I am a software developer. I am checking with the proj people to see how they are tracking the ABI compatibility. For as long as I have used proj, I do not recall seeing this number reported. Since I link against -lproj, my Makefiles just reference the current development RPM that is installed.

This is all correct... -lproj references to libproj.so and it is the -devel package providing this. In turn, it is a symlink on the libproj.so.12 (current version); as long as your API is safe, anything linking -lproj will automatically link libproj.so.12 (on a runtime system, you don't need libproj.so - when you inspect your target binaries, they all use libproj.so.12)

...

I didn't mention that there is also a libproj0 on OBS. I don't think that is ABI version 0. Maybe it is before proj defined ABI version numbers...

IT starts counting at 0; so that is indeed just 'the starting point'

...

Perhaps one should use a label like ABIversion in the spec file. Then it is more obvious that this is where the number is from. There is no guarantee that everyone setting this number is doing so for the same reason.

A lot of spec files use %define sover 0; but it does not change anything practiclaly speaking. there is also rpmlint checking that the number picked matches what the library claims it to be. Those numbers are really not picked by random by packagers. Cheers, Dominique

Roger Oberholtzer

10:23

On Fri, Oct 27, 2017 at 12:00 PM, Dominique Leuenberger / DimStar wrote:

...

A lot of spec files use %define sover 0; but it does not change anything practiclaly speaking. there is also rpmlint checking that the number picked matches what the library claims it to be. Those numbers are really not picked by random by packagers.

I guess rpmlint cannot do this on mingw cross-compiles as the DLL probably does not have the equivalent SOVERSION. So one has to trust the packager to get this correct. Which I am trying to do. -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Jan Engelhardt

11:31

On Friday 2017-10-27 12:23, Roger Oberholtzer wrote:

...

On Fri, Oct 27, 2017 at 12:00 PM, Dominique Leuenberger / DimStar wrote:

...
A lot of spec files use %define sover 0; but it does not change anything practiclaly speaking. there is also rpmlint checking that the number picked matches what the library claims it to be. Those numbers are really not picked by random by packagers.

I guess rpmlint cannot do this on mingw cross-compiles as the DLL probably does not have the equivalent SOVERSION.

There is an equivalent (see ... windows:mingw:win*), but rpmlint indeed is not set up to recognize it.

...

So one has to trust the packager to get this correct. Which I am trying to do.

If your lib %files section does __without globbing on the major__ (something I recommend to anyone, even with ELF), you will definitely not miss a change. %files -n libfoo42 %_mingw64_bindir/libfoo-42.dll -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Dave Plater

28 Oct 28 Oct

13:37

On 27/10/2017 12:23, Roger Oberholtzer wrote:

...

On Fri, Oct 27, 2017 at 12:00 PM, Dominique Leuenberger / DimStar wrote:

...
A lot of spec files use %define sover 0; but it does not change anything practiclaly speaking. there is also rpmlint checking that the number picked matches what the library claims it to be. Those numbers are really not picked by random by packagers.

I guess rpmlint cannot do this on mingw cross-compiles as the DLL probably does not have the equivalent SOVERSION.

So one has to trust the packager to get this correct. Which I am trying to do.

You can check for abi changes with abi-compliance-checker, it's a perl executable so it should work on anything with perl. Dave P -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Roger Oberholtzer

30 Oct 30 Oct

07:21

On Sat, Oct 28, 2017 at 3:37 PM, Dave Plater wrote:

...

You can check for abi changes with abi-compliance-checker, it's a perl executable so it should work on anything with perl.

I found this: https://abi-laboratory.pro/tracker/timeline/proj/ Nice to learn something new. Now to see how the other packages I have in OBS are in this respect. -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Dave Plater

16:13

On 30/10/2017 09:21, Roger Oberholtzer wrote:

...

On Sat, Oct 28, 2017 at 3:37 PM, Dave Plater wrote:

...
You can check for abi changes with abi-compliance-checker, it's a perl executable so it should work on anything with perl.

I found this:

https://abi-laboratory.pro/tracker/timeline/proj/

Nice to learn something new. Now to see how the other packages I have in OBS are in this respect.

I see it uses the abi-compliance-checker suit. Dave P -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Michal Kubecek

27 Oct 27 Oct

09:31

On Friday, 27 October 2017 11:18 Roger Oberholtzer wrote:

...

proj exists in two places (at least):

https://build.opensuse.org/package/show/Application%3AGeo/proj where it is called libproj12 (from source proj4.9.3)

https://build.opensuse.org/package/show/openSUSE%3ALeap%3A42.3/proj where is is called libproj9 (from source proj4.9.2)

The use of 9 or 12 in the name has nothing at all to do with the proj source. It is, I think, a rather arbitrary number assigned to the name by the packager in OBS. There is no property in proj to which it refers.

There is, it's library soname as you found yourself below. Please read https://en.opensuse.org/openSUSE:Shared_library_packaging_policy Michal Kubeček

...

proj is not the only package that does this.

Why is this done? So many other packages have different versions available, and they do not resort to adding a strange number to the name to differentiate them.

And what is even more obtuse is that the libraries are named with these numbers that have nothing at all to do with the package:

/usr/lib64//libproj.so -> libproj.so.12.0.0 /usr/lib64//libproj.so.12 -> libproj.so.12.0.0 /usr/lib64//libproj.so.12.0.0

-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

2376

Age (days ago)

2379

Last active (days ago)

List overview

Download

9 comments

5 participants

participants (5)

Dave Plater
Dominique Leuenberger / DimStar
Jan Engelhardt
Michal Kubecek
Roger Oberholtzer

[opensuse-factory] Package naming conventions

tags

participants (5)