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