Bug#610933: [Pkg-vsquare-devel] Bug#610933: libvdeplug3 declares a conflict with libvdeplug2
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 -- IRC: garden@freenode OpenPGP: 1024D/63D2D5D907F89BB8 Jabber/gtalk: garde...@gmail.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#610933: libvdeplug3 declares a conflict with libvdeplug2
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. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#610933: [Pkg-vsquare-devel] Bug#610933: libvdeplug3 declares a conflict with libvdeplug2
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
--
IRC: garden@freenode
OpenPGP: 1024D/63D2D5D907F89BB8 Jabber/gtalk: garde...@gmail.com
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#610933: libvdeplug3 declares a conflict with libvdeplug2
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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#610933: libvdeplug3 declares a conflict with libvdeplug2
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. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#610933: [Pkg-vsquare-devel] Bug#610933: libvdeplug3 declares a conflict with libvdeplug2
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 -- IRC: garden@freenode OpenPGP: 1024D/63D2D5D907F89BB8 Jabber/gtalk: garde...@gmail.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#610933: libvdeplug3 declares a conflict with libvdeplug2
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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#610933: [Pkg-vsquare-devel] Bug#610933: libvdeplug3 declares a conflict with libvdeplug2
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 -- IRC: garden@freenode OpenPGP: 1024D/63D2D5D907F89BB8 Jabber/gtalk: garde...@gmail.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#610933: libvdeplug3 declares a conflict with libvdeplug2
# 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. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#610933: libvdeplug3 declares a conflict with libvdeplug2
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. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#610933: libvdeplug3 declares a conflict with libvdeplug2
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. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
