Re: Hamlib status in Debian
Hi Ervin!
On 03/26/2016 01:00 PM, Ervin Hegedüs - HA2OS wrote:
> As you can see, the naming convention is not so consistent. There
> are some packages with simple "hamlib" pattern, and there are
> some with hamlib2. I don't know, what was the reason that so
> envolved.
The reason for the numeral suffix are different ABI versions of
a shared libary.
A library called "libfoo.so.1" indicates an ABI version of "1" and
the library package is consequently called "libfoo1". If a library
has the ABI version "2", then the SO file should be called "libfoo.so.2"
and, consequently, the library package "libfoo2".
This is necessary because applications which link against those shared
libraries are usually not compatible with arbitrary ABI versions and
the package manager needs to make sure that the library package
with the proper ABI version is installed when installing a certain
application package.
Thus, if you install the application package "bar" and it requires
the library "libfoo.so.2", then dpkg needs to make sure "libfoo2"
is installed as well.
If library packages didn't have the ABI suffix in their package name,
there wouldn't be an easy way to distinct different ABI versions.
Note that simply using a different package versions wouldn't be
enough since ABI versions usually have no direct connections to
a package version.
See the Debian Policy for more [1].
As for the "ubuntu" suffix, that just means the package was repackaged
or updated for Ubuntu. This allows Debian and Ubuntu maintainers and
users to quickly determine the origin of a package. Without the
suffix, the package can normally be assumed to be imported from
Debian to Ubuntu.
> I think that would be switch to a new naming convention: the new
> package hierarchy called by hamlib3, eg: libhamlib3++-dev,
> libhamlib3-dev, ... libhamlib3-perl, python-libhamlib3. All
> packages could built from 3.1 Git version.
No, for the aforeentioned reasons you shouldn't do that. As long
as the ABI version of the libary doesn't change, you shouldn't
change the ABI version suffix in the package name.
> But there are several "dummy" (?) package, which named hamlib1,
> hamlib2, hamlib3, hamlib4 - why are these package names exists?
> I see, that all of them are virtual packages, but why had created
> them?
Where are you seeing these? 'apt-cache search' doesn't list them
on Debian unstable.
> What do you think about these? How can I help to you to start to
> make the new packages?
I suggest you start reading the Debian New Maintainer's Guide [2].
This will help you to answer most of your questions why certain
things are done in a particular way within Debian.
Cheers,
Adrian
> [1] https://www.debian.org/doc/debian-policy/ch-sharedlibs.html
> [2] https://www.debian.org/doc/manuals/maint-guide/
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz@debian.org
`. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Reply to: