Re: libsvn0-1.2.3dfsg1-2bpo1: missing perl swig bindings
On Wed, Mar 22, 2006 at 01:38:56PM -0500, GNU Dev wrote:
> diff $(root@server1:~/#dpkg -L libsvn0 | sort) $(root@server2:~/#dpkg -L
> libsvn0 | sort)
> < /usr/lib/libsvn_swig_perl-1.so.0
> < /usr/lib/libsvn_swig_perl-1.so.0.0.0
> < /usr/lib/libsvn_swig_py-1.so.0
> < /usr/lib/libsvn_swig_py-1.so.0.0.0
> > /usr/share/doc/libsvn0/changelog.gz
> When I said it should be an easy fix, to clarify, the pkg just needs to be
> compiled with the right flags to ./configure, i.e. --with-perl
> --with-python, or something like that. I can't imagine why this would be
> difficult to accomplish. I'd do it myself if I was set up for generating
> .debs and submitting them to backports.org.
Well actually it's not that easy. Those files you get there are just
symlinks. The lib itself resisted in the libsvn0-dev package like you can
find out with apt-file on a stable system:
sven@arthur:~$ apt-file search libsvn_swig
Well on the side of solving this problem the real problem is that backports
are about mostly about recompiling the package from testing and _not_ modify
them. In this case we've the problem of a (small) regression because the
bundling of the lib seems to have changed upstream (or only in the package?
I'm not yet sure about that).
So you've two choices:
a) Take it as it is and stay with suversion from stable.
b) Life with the regression and continue to use the backported version
c) Do some cruel things to the package and try to get the lib back in.
IMHO it's best to stay with a) or b).
Anyway it would be great to find out where and why the swig bindings are
gone. Getting your hands on the changelog could help. ;)
If God passed a mic to me to speak
I'd say stay in bed, world
Sleep in peace
[The Cardigans - 03:45: No sleep]