Package naming conventions

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Package naming conventions

Roger Oberholtzer-2
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: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Package naming conventions

Dominique Leuenberger / DimStar
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

signature.asc (201 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Package naming conventions

Michal Kubecek
In reply to this post by Roger Oberholtzer-2
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: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Package naming conventions

Roger Oberholtzer-2
In reply to this post by Dominique Leuenberger / DimStar
On Fri, Oct 27, 2017 at 11:26 AM, Dominique Leuenberger / DimStar
<[hidden email]> 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: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Package naming conventions

Dominique Leuenberger / DimStar
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

signature.asc (201 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Package naming conventions

Roger Oberholtzer-2
On Fri, Oct 27, 2017 at 12:00 PM, Dominique Leuenberger / DimStar
<[hidden email]> 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: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Package naming conventions

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

>On Fri, Oct 27, 2017 at 12:00 PM, Dominique Leuenberger / DimStar
><[hidden email]> 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: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Package naming conventions

Dave Plater lst
In reply to this post by Roger Oberholtzer-2


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

> On Fri, Oct 27, 2017 at 12:00 PM, Dominique Leuenberger / DimStar
> <[hidden email]> 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: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Package naming conventions

Roger Oberholtzer-2
On Sat, Oct 28, 2017 at 3:37 PM, Dave Plater <[hidden email]> 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: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Package naming conventions

Dave Plater lst


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

> On Sat, Oct 28, 2017 at 3:37 PM, Dave Plater <[hidden email]> 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: [hidden email]
To contact the owner, e-mail: [hidden email]