[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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 

> > > 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 
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 

Reply to: