Re: Working on dpkg-checkbuilddeps support for dpkg-cross
> Hi people,
>
> On Mon, 2004-12-13 at 21:01, Raphael Bossek wrote:
> > > What algorithm are you going to use for convertion?
> >
> > A very stupid 'keepdeps' and 'replacedeps' by rewrite_dependencies().
>
> Most of the libdependencies can just be rewritten no? Normal package
> dependencies should already be okay. If you change all the
> lib...somethings in lib..something-arch-cross it should be okay.
Not all library packages have their name started from lib. And not only
library package names need to be converted.
An interesting example isbuild-depending on perl. This may mean that host
perl is needed to run a build tool. But this also may mean that some of
perl C headers (also provided by perl, see #285569) is needed. So what to
do with it in checkbuilddeps?
> > > You know, some build-deps should be kept as-is, and some should be
> > > changed to -arch-cross. A good alrorithm is to convert (to
> > > -$arch-cross) packages from lib and libdevel sections, while keeping
>
> Ow it seems this is the same as I was telling higher... If we mean the
> same thing please ignore
Not exact the same. Testing package section is much more reliabe than
testing package name. But section of package in question is not easily
accessable.
>
> > > all the rest as-is. But information of package sections is not
> > > easily available. Converting everything by default and using only
> > > 'keepdeps' and 'ignoredeps' to override is a bad idea IMHO. It will
> > > make these lists completely unmaintainable. And 'ignoredeps' will
> > > become package-dependent.
>
> Well is the package section not the same as the original/native one?
> Correct me if I am wrong, I have the feeling I am missing something. (
> And it is too late to think clearly)
>
> > > Or probably you are faced by problem described at
> > > http://lists.debian.org/debian-devel/2004/11/msg00943.html
> >
> > I'm not sure but I will consider that next time.
>
> Well I would rely on the package info (depends, et al. ) because it
> should already be correct. Of course you can find out all stuff with
> objdump, but is that not too far fetched if it already has been done?
> And it solves the undocumented behaviour problem...
I can't get what you are about, sorry :(.
dpkg-shlibdeps from dpkg-dev depends on running ldd to get lhe list of
shared libs needed by an executable. This can't work for non-native
binaries (because ldd actually executes binary in special dynamic linker
mode).
dpkg-shlibdeps from dpkg-cross gets the same information using objdump.
The undocumented behaviour of shlibdeps is not about getting the list of
required .so files, but about finding shlibs information of those .so
files (how to map .so files to package names on which package being
generated should depend). The procedure how this should be done is
documented in dpkg-shlibdeps(8), and dpkg-shlibdeps from dpkg-cross
implements exactly this procedure (this code was just taken from original
dpkg-shlibdeps on the fork time). However, dpkg-shlibdeps from current
dpkg-dev uses not that documented procedure, but also searches other
places for local shlibs information. This is not currently duplicated in
dpkg-cross's version, so cross-build of packages that happen to depend on
this fail.
Or you mean 'take a natively built package and see what depends: is there"?
I can't agree with this. If we go this way, what is rationale of any
cross-compilation?
Reply to: