Discussion:
Bug#863030: Do not encode soversion in source and dev package name
(too old to reply)
Simon Josefsson
2017-07-17 07:00:02 UTC
Permalink
Raw Message
Hi Michael. I don't agree with renaming the package name. The debian
policy manual says in section 8.1 [1] that:

The run-time shared library must be placed in a package whose
name changes whenever the SONAME of the shared
       library changes.  This allows several versions of the shared
       library to be installed at the same time, allowing installation
of the new version of the shared library without immediately
breaking binaries that depend on the old version.  Normally,
the run-time shared library and its SONAME symlink should be
       placed in a package named librarynamesoversion, where soversion
is the version number in the SONAME of the shared library.
       Alternatively, if it would be confusing to directly append
       soversion to libraryname (if, for example, libraryname itself
ends in a number), you should use libraryname-soversion instead.

This is what I believe we are doing. Can you explain more in detail
what is wrong? From my reading, we are doing what we should do, and
what you suggest would not be consistent with the above.

/Simon

[1] https://www.debian.org/doc/debian-policy/ch-sharedlibs.html#s-share
dlibs-runtime
Simon Josefsson
2017-07-17 10:10:01 UTC
Permalink
Raw Message
Hi Michael.  I don't agree with renaming the package name.  The
debian
       The run-time shared library must be placed in a package
whose
       name changes whenever the SONAME of the shared
       library changes.  This allows several versions of the shared
       library to be installed at the same time, allowing
installation
       of the new version of the shared library without immediately
       breaking binaries that depend on the old version.  Normally,
       the run-time shared library and its SONAME symlink should be
       placed in a package named librarynamesoversion, where
soversion
       is the version number in the SONAME of the shared library.
       Alternatively, if it would be confusing to directly append
       soversion to libraryname (if, for example, libraryname
itself
       ends in a number), you should use libraryname-soversion
instead.
This is what I believe we are doing.  Can you explain more in
detail
what is wrong?  From my reading, we are doing what we should do,
and
what you suggest would not be consistent with the above.
I'm talking about the the dev and source package, not the library
package, i.e.
using a soversion in
Package: libidn2-0
is fine, but it's wrong for
Source: libidn2-0
Package: libidn2-0-dev
Use
Source: libidn2
Package: libidn2-dev
instead
Sorry, I misunderstood. Yes, I agree. It could be argued that we
could keep libidn2-0-dev, if we want to allow having multiple versions
around. But this is not likely.

I'll let the package move into testing and then make the change.

Thanks,
/Simon
Michael Biebl
2017-07-17 10:10:02 UTC
Permalink
Raw Message
Post by Simon Josefsson
Use
Source: libidn2
Package: libidn2-dev
instead
Sorry, I misunderstood. Yes, I agree. It could be argued that we
could keep libidn2-0-dev, if we want to allow having multiple versions
around. But this is not likely.
And it wouldn't work anyway as you'll get a file conflict for the .so
symlink (which doesn't have the soversion encoded):
/usr/lib/x86_64-linux-gnu/libidn2.so
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
Michael Biebl
2017-07-17 10:10:02 UTC
Permalink
Raw Message
Post by Simon Josefsson
Hi Michael. I don't agree with renaming the package name. The debian
The run-time shared library must be placed in a package whose
name changes whenever the SONAME of the shared
library changes. This allows several versions of the shared
library to be installed at the same time, allowing installation
of the new version of the shared library without immediately
breaking binaries that depend on the old version. Normally,
the run-time shared library and its SONAME symlink should be
placed in a package named librarynamesoversion, where soversion
is the version number in the SONAME of the shared library.
Alternatively, if it would be confusing to directly append
soversion to libraryname (if, for example, libraryname itself
ends in a number), you should use libraryname-soversion instead.
This is what I believe we are doing. Can you explain more in detail
what is wrong? From my reading, we are doing what we should do, and
what you suggest would not be consistent with the above.
I'm talking about the the dev and source package, not the library
package, i.e.
using a soversion in
Package: libidn2-0
is fine, but it's wrong for

Source: libidn2-0
Package: libidn2-0-dev


Use
Source: libidn2
Package: libidn2-dev
instead
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
Loading...