+++ Barry Drake [2014-04-13 17:51 +0100]:
> Hi ... Can I introduce myself. I've been involved in 'The Sword
> Project' for some years and am now going along the very steep
> learning curve in order to update the packages which are some five
> years out of date. I'm running Ubuntu Trusty 14.04 beta and can
> build the packages with no problem using pdebuild. But - the build
> puts in a dependency on libicu48 which is now removed from the
> Ubuntu repos and replaced with libicu52 which is what the actual
> build from source is using. The control file produced is identical
> to that in the current out-of-date package (1.6.2). I am packaging
> version 1.7.3.
> I've worked out that dpkg is being used to get the dependencies (I
> think) but I haven't a clue as to where it gets them from, or how I
> can change this behaviour. The builder puts them into the
> ${shlibs:Depends} string, and I can't see any method of controlling
> what gets into that string. I've read and re-read the packaging
> startup manual and haven't managed to find what to do. The control
> file produced by the build has the line:
>
> Depends: libsword-common, libc6 (>= 2.4), libclucene-core1 (>=
> 2.3.3.4), libcurl3-gnutls (>= 7.16.2), libgcc1 (>= 1:4.1.1),
> libicu48 (>= 4.8-1), libstdc++6 (>= 4.6), zlib1g (>= 1:1.1.4)
>
> and it needs to have libicu52 (>= 0) as the correct dependency.
I've always been a little vague about the details, but essentiaqlly
the ${shlibs:Depends} variable gets populated by the shlibpeps
mechanism which actually looks at the libraries linked and puts in the
corresponding package names. So if it's putting in libicu48 then
that's almost certainly because that's the library that's actually
getting used in the build.
Looking at the build log should give some clues about which
dependencies get installed.
I would guess that your problem is that the chroot pbuilder is using
is out of date (and thus has libicu48 still around, or is not set to
use only unstable packages?). pbuilder does not update the chroot for
each build by default, you have to update it separately. sbuild does
do an update/upgrade every time by default, which is one major reason
I recommend using it for builds.
So the simple fix is to update your pbuilder chroot, or build with
sbuild instead (which probably involves running sbuild-createchroot to
set up an unstable chroot for it to use (and running sbuild-update
--keygen once to make some keys for apt to use).
Each build gives you a nice log file showing exactly what was
installed to satisfy the build deps, so you shoul dbe able to see
which libicu version was installed.
I've not checked anything, so it could be more subtle than this, but
that's my first guess.
> I hope I've come to the right place to ask this kind of newbie
> question.
You have :-)
> I don't want to become a maintainer, jut to produce the
> build source files and pass them on to one of the existing
> maintainers to sign and submit.
>
> Kind regards, Barry Drake.
>
>
> --
> To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
> Archive: https://lists.debian.org/534ac0af.20...@gmail.com
>
Wookey
--
Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140413194040.go15...@stoneboat.aleph1.co.uk
