Debian Bug report logs - #610933
libvdeplug3 declares a conflict with libvdeplug2

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Jonathan Nieder <jrnieder@gmail.com>

To: submit@bugs.debian.org

Subject: libvdeplug3 declares a conflict with libvdeplug2

Date: Sun, 23 Jan 2011 23:49:33 -0600

Package: libvdeplug3
Version: 2.3.1-1
Severity: important
Justification: policy §8.1

libvdeplug3 declares

	Conflicts: libvdeplug2
	Replaces: libvdeplug2

but the documentation (e.g., the package description) does not
explain a reason.  "dpkg -L libvdeplug2" does not reveal any
unversioned filenames that would cause file conflicts, at least.
Is the conflict needed?

I am hoping not, because it makes the upgrade path more rigid, both
from the point of view of keeping "sid" working during a transition
and keeping a working system during a dist-upgrade.

Thanks for keeping this basic component working well.

Message #10 received at 610933@bugs.debian.org (full text, mbox, reply):

From: Jonathan Nieder <jrnieder@gmail.com>

To: 610933@bugs.debian.org

Subject: Re: libvdeplug3 declares a conflict with libvdeplug2

Date: Mon, 20 Jun 2011 23:43:03 -0500

Hi,

Jonathan Nieder wrote:

> libvdeplug3 declares
> 
> 	Conflicts: libvdeplug2
> 	Replaces: libvdeplug2
[...]
> Is the conflict needed?

Ping?  I've had vde2 on hold because of this bug for several months
now.  IMHO if the package in experimental is not being maintained, it
should be removed --- it will still be available from
snapshot.debian.org.

Message #15 received at 610933@bugs.debian.org (full text, mbox, reply):

From: Jonathan Nieder <jrnieder@gmail.com>

To: 610933@bugs.debian.org

Subject: Re: libvdeplug3 declares a conflict with libvdeplug2

Date: Sun, 6 Nov 2011 02:01:05 -0600

# no upgrade path
severity 610933 serious
# (luckily this package is only in experimental)
quit

Jonathan Nieder wrote:

> libvdeplug3 declares
>
> 	Conflicts: libvdeplug2
> 	Replaces: libvdeplug2
[...]
> Is the conflict needed?

Raising severity so users can tell to avoid it for now.  Thanks for
packaging recent vde.  If there's anything I can provide to help (a
patch?), just ask.

Message #22 received at 610933@bugs.debian.org (full text, mbox, reply):

From: Ludovico Gardenghi <garden@debian.org>

To: Jonathan Nieder <jrnieder@gmail.com>, 610933@bugs.debian.org

Subject: Re: [Pkg-vsquare-devel] Bug#610933: libvdeplug3 declares a conflict with libvdeplug2

Date: Mon, 28 Nov 2011 12:28:01 +0100

Hello,

On Mon, Jun 20, 2011 at 23:43:03 -0500, Jonathan Nieder wrote:

> Ping?  I've had vde2 on hold because of this bug for several months
> now.  IMHO if the package in experimental is not being maintained, it
> should be removed --- it will still be available from
> snapshot.debian.org.

Thanks for the report and sorry for the delay.

Indeed the conflict will be needed with the next release, as we're
much probably going to move libvdeplug.so from the -dev package to the
shared library one (since several virtualization tools which use VDE
call dlopen with the non-versioned name, see #536373 for example).

VDE version 2.3.2 is going to be released soon in unstable.

Ludovico
-- 
<lu@dovi.co>                                        IRC: garden@freenode
OpenPGP: 1024D/63D2D5D907F89BB8         Jabber/gtalk: gardengl@gmail.com

Message #27 received at 610933@bugs.debian.org (full text, mbox, reply):

From: Jonathan Nieder <jrnieder@gmail.com>

To: Ludovico Gardenghi <garden@debian.org>

Cc: 610933@bugs.debian.org

Subject: Re: libvdeplug3 declares a conflict with libvdeplug2

Date: Mon, 28 Nov 2011 05:34:31 -0600

Hi Ludovico,

Ludovico Gardenghi wrote:

> Thanks for the report and sorry for the delay.

No problem and glad to hear from you.

> Indeed the conflict will be needed with the next release, as we're
> much probably going to move libvdeplug.so from the -dev package to the
> shared library one

That violates policy §8.1 "Run-time shared libraries" and would make
smooth upgrades of packages that use the shared library difficult.

> (since several virtualization tools which use VDE
> call dlopen with the non-versioned name, see #536373 for example).

Would it be possible to make a different package, such as vde2,
provide the non-versioned symlink, and such packages depend on it?

> VDE version 2.3.2 is going to be released soon in unstable.

Thanks for the update.  If there's anything I can do to help, let me
know.

Regards,
Jonathan

Message #32 received at 610933@bugs.debian.org (full text, mbox, reply):

From: Ludovico Gardenghi <garden@debian.org>

To: Jonathan Nieder <jrnieder@gmail.com>, 610933@bugs.debian.org

Subject: Re: [Pkg-vsquare-devel] Bug#610933: libvdeplug3 declares a conflict with libvdeplug2

Date: Mon, 28 Nov 2011 16:06:56 +0100

On Mon, Nov 28, 2011 at 05:34:31 -0600, Jonathan Nieder wrote:

> > Indeed the conflict will be needed with the next release, as we're
> > much probably going to move libvdeplug.so from the -dev package to the
> > shared library one
> 
> That violates policy §8.1 "Run-time shared libraries" and would make
> smooth upgrades of packages that use the shared library difficult.

I understand that putting a .so symlink, in general, is against the
policy. Yet I saw this sentence at the beginning of chapter 8:

    "[...] the bare .so symlink is installed in the development package
    since it's only used when linking binaries or shared libraries.
    However, there are some exceptions for unusual shared libraries or
    for shared libraries that are also loaded as dynamic modules by
    other programs."

This is the case with libvdeplug: it's both linked at compile time and
dlopen()ed at runtime, depending on the software which uses it.
Do you think it would still be a policy violation?

(In any case, I still can't figure out what should be the *proper* way
for a program for dlopening a .so while providing the version number...
should it loop over all the (infinite :-)) possible SONAMEs who offer
compatibility for the needed interface version?

> > (since several virtualization tools which use VDE
> > call dlopen with the non-versioned name, see #536373 for example).
> 
> Would it be possible to make a different package, such as vde2,
> provide the non-versioned symlink, and such packages depend on it?

It would be unpractical to put the .so symlink in the vde2 package,
since then the -dev one should depend on vde2 (if I'm not wrong). Should
we create a tiny package with only a single symlink in it? I haven't
checked yet how other packagers solved the problem, so maybe the
solution already exists :-)...

Thanks,
Ludovico
-- 
<lu@dovi.co>                                        IRC: garden@freenode
OpenPGP: 1024D/63D2D5D907F89BB8         Jabber/gtalk: gardengl@gmail.com

Message #37 received at 610933@bugs.debian.org (full text, mbox, reply):

From: Jonathan Nieder <jrnieder@gmail.com>

To: Ludovico Gardenghi <garden@debian.org>

Cc: 610933@bugs.debian.org

Subject: Re: libvdeplug3 declares a conflict with libvdeplug2

Date: Mon, 28 Nov 2011 17:59:00 -0600

Ludovico Gardenghi wrote:

> (In any case, I still can't figure out what should be the *proper* way
> for a program for dlopening a .so while providing the version number...
> should it loop over all the (infinite :-)) possible SONAMEs who offer
> compatibility for the needed interface version?

Ah!  Well, it's true that SONAMEs are not a perfect description of
whether the relevant part of the interface changed or not.

When the SONAME is bumped, programs that linked directly to the
library still are linked to the old version.  This has a few
implications:

 1. If you want to dlopen a shared library, in general one practical
    way to do so is to call "readlink" on the .so symlink at build
    time and then strip off the minor version (for example in your
    configure script) and bake in the target.  This way, if later
    versions of the shared library change or remove the interfaces you
    are using, your program will still work.

    Is there any particular reason for libvdeplug_dyn.h to use the
    unversioned name instead of "libvdeplug.so.3"?

 2. If the SONAME of a shared library is changing very often, that
    means old programs linking to the old version are going to
    cause a lot of crufty old versions to be kept around on some
    machines.  If the SONAME is bumping often enough for this to
    be a problem, it can be useful to find ways to make the interface
    a little more stable :) --- for example, by using opaque types,
    and by using symbol versioning to version backward-compatible
    ABI extensions.

Message #42 received at 610933-close@bugs.debian.org (full text, mbox, reply):

From: Ludovico Gardenghi <garden@debian.org>

To: 610933-close@bugs.debian.org

Subject: Bug#610933: fixed in vde2 2.3.2-1

Date: Thu, 19 Jan 2012 10:48:36 +0000

Source: vde2
Source-Version: 2.3.2-1

We believe that the bug you reported is fixed in the latest version of
vde2, which is due to be installed in the Debian FTP archive:

libvde-dev_2.3.2-1_amd64.deb
  to main/v/vde2/libvde-dev_2.3.2-1_amd64.deb
libvde0_2.3.2-1_amd64.deb
  to main/v/vde2/libvde0_2.3.2-1_amd64.deb
libvdeplug-dev_2.3.2-1_amd64.deb
  to main/v/vde2/libvdeplug-dev_2.3.2-1_amd64.deb
libvdeplug2_2.3.2-1_amd64.deb
  to main/v/vde2/libvdeplug2_2.3.2-1_amd64.deb
vde2-cryptcab_2.3.2-1_amd64.deb
  to main/v/vde2/vde2-cryptcab_2.3.2-1_amd64.deb
vde2_2.3.2-1.diff.gz
  to main/v/vde2/vde2_2.3.2-1.diff.gz
vde2_2.3.2-1.dsc
  to main/v/vde2/vde2_2.3.2-1.dsc
vde2_2.3.2-1_amd64.deb
  to main/v/vde2/vde2_2.3.2-1_amd64.deb
vde2_2.3.2.orig.tar.gz
  to main/v/vde2/vde2_2.3.2.orig.tar.gz



A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 610933@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Ludovico Gardenghi <garden@debian.org> (supplier of updated vde2 package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Format: 1.8
Date: Thu, 19 Jan 2012 11:35:11 +0100
Source: vde2
Binary: vde2 vde2-cryptcab libvdeplug-dev libvdeplug2 libvde-dev libvde0
Architecture: source amd64
Version: 2.3.2-1
Distribution: unstable
Urgency: low
Maintainer: Debian VSquare Team <pkg-vsquare-devel@lists.alioth.debian.org>
Changed-By: Ludovico Gardenghi <garden@debian.org>
Description: 
 libvde-dev - Virtual Distributed Ethernet - support libraries development file
 libvde0    - Virtual Distributed Ethernet - support libraries
 libvdeplug-dev - Virtual Distributed Ethernet - Plug development files
 libvdeplug2 - Virtual Distributed Ethernet - Plug library
 vde2       - Virtual Distributed Ethernet
 vde2-cryptcab - Virtual Distributed Ethernet - CryptCab
Closes: 610933 636745 646627
Changes: 
 vde2 (2.3.2-1) unstable; urgency=low
 .
   * New upstream version
   * Remove Piotr Roszatycki <dexter@debian.org> from Uploaders
     (Closes: #636745)
   * Suggest qemu-kvm instead of dummy transitional package kvm
     (Closes: #646627)
   * Add major version in dlopen in libvdeplug_dyn.h to avoid binary dependency
     on -dev package (for additional explanations see the header file itself)
     Patch file: debian/patches/libvdeplug_dyn_versioned_dlopen.patch
   * Add patch for fixing missing format string in fprintf() and syslog()
     calls. Patch file: debian/patches/printf_add_format_string.patch
   * Add patch for fixing "wrong" SONAME for libraries. -version-number had
     been used instead of version-info, this gave incorrect SONAMEs and broke
     compatibility between this version and the previous ones (althought there
     is no actual ABI incompatibility).
     Patch file: debian/patches/fix_soname_version_info.patch
     - reset libvdeplug name to libvdeplug2 (w.r.t 2.3.1-1) (Closes: #610933)
   * Move /usr/lib/libvdetap.a to -dev package
   * Update Standards-Version to 3.9.2: nothing to do
   * Switch to CDBS and quilt
   * Remove useless .dirs files
Checksums-Sha1: 
 31af8038bbfed3cf772e068e6796357ffc17c377 1895 vde2_2.3.2-1.dsc
 72552d58eba1309e219d73de4d18047a530f6f47 770257 vde2_2.3.2.orig.tar.gz
 62f7edd1a2374a8237dccfeb9fe957eeaab8b14d 11984 vde2_2.3.2-1.diff.gz
 bb5d446383d04a5a3d306a553b034e6735b4fcf5 236322 vde2_2.3.2-1_amd64.deb
 5c363d7cdd59544dc203798c75a813d4b9bc8218 26150 vde2-cryptcab_2.3.2-1_amd64.deb
 7de6a61e6daa0744cbf72ca0f2e3059fa1221b95 24450 libvdeplug-dev_2.3.2-1_amd64.deb
 0f297977317383037aa808b452dd8b5f0887327d 22874 libvdeplug2_2.3.2-1_amd64.deb
 a9f3dab0652efd5d725b4c53d12556a5f68fbea0 42620 libvde-dev_2.3.2-1_amd64.deb
 71cbb84bd75aeeba8947fe5a687a52838261234c 37390 libvde0_2.3.2-1_amd64.deb
Checksums-Sha256: 
 38e57eed7348271db5c98fca4c7b39f343c1e97e83c08df72ecda56347f555b1 1895 vde2_2.3.2-1.dsc
 22df546a63dac88320d35d61b7833bbbcbef13529ad009c7ce3c5cb32250af93 770257 vde2_2.3.2.orig.tar.gz
 3e58ba4cc760813fcf1e71ac88348dab067e6c8c4a31909cab8f9050dee292f1 11984 vde2_2.3.2-1.diff.gz
 df99d2e75d22cc725bb3cbfc246a253c1e262ed33a9c2a874d81213e6440042d 236322 vde2_2.3.2-1_amd64.deb
 6191786a79972b2e59a8f73132b504f4e86983e01eed4633e89729fa7a33765d 26150 vde2-cryptcab_2.3.2-1_amd64.deb
 80aa2fb4c12a70987e6d6497f62586bc7a91b72d92242933a948f4691fac9df0 24450 libvdeplug-dev_2.3.2-1_amd64.deb
 db6be49e47c9b865bc8324886ba03530220a6b8a86cb2ba20dcd35ce245d8a5d 22874 libvdeplug2_2.3.2-1_amd64.deb
 58547f4e448b71818c4fd9f1cc696a25cdd77481dce59ccf39a490f641a2e7dc 42620 libvde-dev_2.3.2-1_amd64.deb
 0c41ca21760a4ff8ee6ea737fcf5bf1f8137606c2fe4bb7494924643abb9d17b 37390 libvde0_2.3.2-1_amd64.deb
Files: 
 ddf1138ed0ea6f7d4b9c32aa03a1e77d 1895 net optional vde2_2.3.2-1.dsc
 d3f3e979558e396b8405c4613df9dfa0 770257 net optional vde2_2.3.2.orig.tar.gz
 fc17f5118719a497b37cb860d09a031f 11984 net optional vde2_2.3.2-1.diff.gz
 04eebd4a5bec7b68c6d639f6ef2efb4d 236322 net optional vde2_2.3.2-1_amd64.deb
 be3026bba2ab8bceebcb779f14fe8e0e 26150 net optional vde2-cryptcab_2.3.2-1_amd64.deb
 36009cbd770ad68de7780a533c00cf9e 24450 libdevel optional libvdeplug-dev_2.3.2-1_amd64.deb
 fda048138a177ddaea5a1b6c26790473 22874 libs optional libvdeplug2_2.3.2-1_amd64.deb
 9793ae201884a8e667fb3ef4f79b70dd 42620 libdevel optional libvde-dev_2.3.2-1_amd64.deb
 24515c4693c5f8c0b20e7d5827077971 37390 libs optional libvde0_2.3.2-1_amd64.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQEcBAEBCAAGBQJPF/LUAAoJEPXTSIpdwmASYEQIAIMIV9Goa/9M/WDp7iJuy+Js
531cYrlSYsWEMJ5I8daYUF1tRS2xOCSDBoJZHXSyOtt91BQwl8jgx2W7zzf4vaWo
Y2BZb9XP1OK+JL03zUM9JSrsfDS9aoWP+bLdDRPo9K7Ltjpp8IeOJ1+L3mFGYUdV
nn/q0ePDu1S8ZBarP3rSFG/U25vSIWWZKHIE87H+BrJA490shT2Py8FKwSFqfXyT
PlJ1ixHq9uAo8NsDq6f7/AVbYtPb0uR18IzeDYk6qboV5gxvAclGgutIVzj+sh8h
jRGRjaKsY3adlTHIucYJgWGSkT10LHVt9YYheVJF9LtjCHRU74FTCBWsD0gMzOY=
=UBiN
-----END PGP SIGNATURE-----

Message #47 received at 610933@bugs.debian.org (full text, mbox, reply):

From: Jonathan Nieder <jrnieder@gmail.com>

To: 610933@bugs.debian.org

Subject: Re: libvdeplug3 declares a conflict with libvdeplug2

Date: Thu, 19 Jan 2012 05:06:30 -0600

Ludovico Gardenghi wrote:

>    * Add patch for fixing "wrong" SONAME for libraries. -version-number had
>      been used instead of version-info, this gave incorrect SONAMEs and broke
>      compatibility between this version and the previous ones (althought there
>      is no actual ABI incompatibility).

Thanks, Ludovico!  This is great.

Some tiny questions from looking over the diff:

> * If this header file is used to generate binaries meant to be used on other
> * distributions, it could be safe to redefine LIBVDEPLUG_DLOPEN_FILENAME with
> * the unversioned name.

Do the various distros not agree on a soname for libvdeplug?

> # There is a copyright file for each package, so the debian/copyright file is
> # not needed.

I think ftpmasters tend to rely on debian/copyright documenting the
copyright of the source package.

Happy,
Jonathan

Message #52 received at 610933@bugs.debian.org (full text, mbox, reply):

From: Ludovico Gardenghi <garden@debian.org>

To: Jonathan Nieder <jrnieder@gmail.com>, 610933@bugs.debian.org

Subject: Re: [Pkg-vsquare-devel] Bug#610933: libvdeplug3 declares a conflict with libvdeplug2

Date: Thu, 19 Jan 2012 12:40:32 +0100

On Thu, Jan 19, 2012 at 05:06:30 -0600, Jonathan Nieder wrote:

> >    * Add patch for fixing "wrong" SONAME for libraries. -version-number had
> >      been used instead of version-info, this gave incorrect SONAMEs and broke
> >      compatibility between this version and the previous ones (althought there
> >      is no actual ABI incompatibility).
> 
> Thanks, Ludovico!  This is great.

I had to modify the SONAME in Debian w.r.t. the current upstream SONAME,
and I tried to do this in the safest way I could imagine, although it is
not 100% conformant to the typical libtool current/revision/age
progression (I bumped from 3:1:0 to 3:2:1). I discussed the thing a bit
with some of the other upstream people (I am part of them) and it seemed
safe enough -- we're going to update the upstream as well in the near
future with the same patch I applied for Debian.

I hope this won't generate havoc and chaos.

> Some tiny questions from looking over the diff:
> 
> > * If this header file is used to generate binaries meant to be used on other
> > * distributions, it could be safe to redefine LIBVDEPLUG_DLOPEN_FILENAME with
> > * the unversioned name.
> Do the various distros not agree on a soname for libvdeplug?

I am aware that, for instance, the upstream of Virtualbox does a
dlopen("libvdeplug.so"), while the Debian package has a patch for
dlopening libvdeplug.so.2. So I guess there may be other software out
there who would like to redefine this.

vde and its libraries has been used for creating stand-alone images of
virtual machines (e.g. for education purposes) or other custom
environments, so I added this possibility so to let other people use the
libvdeplug_dyn.h header for building, on Debian, software that will be
used with other distributions or in different situations.

Moreover, given the "-version-number" vs "-version-info" problem I
described in the changelog, there are people who will have to deal with
the "wrong" libvdeplug.so.3 which comes from the current upstream SVN
revision.

I know all this is not proper/clean, but I'm not sure there is a really
clean way to deal with this without uselessly breaking backward
compatibility. It seemed cleaner than keeping 3:1:0 and creating
symlinks .so.2 -> .so.3 or similar.

> > # There is a copyright file for each package, so the debian/copyright file is
> > # not needed.
> I think ftpmasters tend to rely on debian/copyright documenting the
> copyright of the source package.

Uhm, ok. I started creating an "unified" copyright file but I noticed I
was duplicating information by hand -- then I thought it would have been
better to make without debian/copyright rather than to have to keep
debian/copyright in sync with debian/*.copyright manually, with the
potential inconsistencies this could generate. But if that's required I
can do it.

Ludovico
-- 
<lu@dovi.co>                                        IRC: garden@freenode
OpenPGP: 1024D/63D2D5D907F89BB8         Jabber/gtalk: gardengl@gmail.com

Message #57 received at 610933@bugs.debian.org (full text, mbox, reply):

From: Jonathan Nieder <jrnieder@gmail.com>

To: Ludovico Gardenghi <garden@debian.org>

Cc: 610933@bugs.debian.org

Subject: Re: libvdeplug3 declares a conflict with libvdeplug2

Date: Thu, 19 Jan 2012 13:58:01 -0600

Ludovico Gardenghi wrote:

>                                          I'm not sure there is a really
> clean way to deal with this without uselessly breaking backward
> compatibility. It seemed cleaner than keeping 3:1:0 and creating
> symlinks .so.2 -> .so.3 or similar.

Makes sense.

> Uhm, ok. I started creating an "unified" copyright file but I noticed I
> was duplicating information by hand -- then I thought it would have been
> better to make without debian/copyright rather than to have to keep
> debian/copyright in sync with debian/*.copyright manually, with the
> potential inconsistencies this could generate. But if that's required I
> can do it.

Oh, that seems reasonable.  This seems to have been discussed recently
on the debian-policy list (search for "I don't think there's much gain
in relaxing this"):

 http://bugs.debian.org/556015#141
 http://bugs.debian.org/556015#224

If I understand correctly, it probably would not be too harmful to
allow the split-up style, but for simplicity policy doesn't allow it
currently.

Message #62 received at 610933@bugs.debian.org (full text, mbox, reply):

From: Ludovico Gardenghi <garden@debian.org>

To: Jonathan Nieder <jrnieder@gmail.com>, 610933@bugs.debian.org

Subject: Re: [Pkg-vsquare-devel] Bug#610933: libvdeplug3 declares a conflict with libvdeplug2

Date: Fri, 20 Jan 2012 22:29:50 +0100

On Thu, Jan 19, 2012 at 13:58:01 -0600, Jonathan Nieder wrote:

> Oh, that seems reasonable.  This seems to have been discussed recently
> on the debian-policy list (search for "I don't think there's much gain
> in relaxing this"):
> 
>  http://bugs.debian.org/556015#141
>  http://bugs.debian.org/556015#224

Thanks for the links. I wanted to make another upload for trying to
build on kfreebsd and I took the opportunity to remove the split files
and use a single debian/copyright. One lintian-override less. :-)

Ludovico
-- 
<lu@dovi.co>                                        IRC: garden@freenode
OpenPGP: 1024D/63D2D5D907F89BB8         Jabber/gtalk: gardengl@gmail.com

Send a report that this bug log contains spam.