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
--
<l...@dovi.co> 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
