Re: Real newbie ....
Hi Barry,
Am Sonntag, den 13.04.2014, 17:51 +0100 schrieb Barry Drake:
> 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.
Can you please give a reference to your package? Maybe taking a look at
it gives some clues :) Best would be to upload it to mentors.debian.net
One possibility just came to my mind: Did you update your pbuilder
environment before building it?
> 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.
Usually dpkg-shlibdeps is right in determining the dependencies.
Without source its hard to check the root-cause.
Maybe the Build-Dependencies are wrong, or you still have the old
library installed (and/or the old -dev package)? Are you building with
the unstable repositories (and your e.g chroot up-to-date)?
> I hope I've come to the right place to ask this kind of newbie
> question. 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.
Well, that's usually not that easy... Of course you can prepare the
upload, but still the maintainer has to do several extra checks before
he can sign it off and indeed upload it. A well-prepared patch certainly
is of great value, but the best would be to offer co-maintaince ... Or
if you "upstream" to help as the upstream contact. I my experience this
helps a lot, as in my experience "upstream" perceives the details of
packaging work different than the actually needs of Debian. (This is
usually well-meant, don't get me wrong, but there a just so many details
to consider. This is for example why upstream never should ship
a /debian directory in its source tarball ...)
> Kind regards, Barry Drake.
>
>
Reply to: