I think I know now what the problem is, see below... On Thu, Mar 16, 2006 at 07:35:41PM +0300, Nikita V. Youshchenko wrote: > > > > As you see, I get depends with -dcv1 suffix as well as -cross suffix. > > Yes, it's exactly what it should do. > Each package xxx-arm-cross package created with dpkg-cross >= 1.26 will > Provide: xxx-arm-dcv1. In your case, this will not allow libc6-arm-cross > created by older dpkg-cross to satisfy dependency - while libc6-arm-cross > created by dpkg-cross >= 1.26 will satisfy it. > > And that's correct, because previously dpkg-cross installed files > info /usr/arm-linux/, and now it will install files to /usr/arm-linux-gnu/ > - so libc6-arm-cross created by older dpkg-cross can't satisfy the > dependency.
Yes, I could guess all of this. However, why do I get -dcv1 as well as -cross?. Aren't they exclusive? Also, a quick grep in my old sources for dpkg-cross-1.25 reveals that already that version had -gnu stuff in... When I try to install generated -cross package I get unresolved dependencies for libgcc1-arm-dcv1. This package is really called libgcc1-arm-cross and is originated in the gcc source package, and thus is not coming from dpkg-cross. Did you already contribute a patch for gcc/build/control that fixes this? > > > The need for versioning does not justify IMHO the uglyness of > > -dcv1 when compared to -cross. And it just "feels" wrong, since it is > > not the type or instances of the files in the package that changed, > > but the "packaging" of these files... Why couldn't you solve that > > with version strings? > > I don't see how version string can be safely used here - because version > strings from original debs are already used to handle dependences. There > are two different dependency requirements - one that original packages > should have version not less than ..., and other - that dpkg-cross should > be fresh enough to place files inside new tree. I don't see way to use > single version strings to handle both things. Maybe embed a -dcvX in the version string? > > > > > Also, would you welcome patches that add the ability to handle > > > > packages built with alternative libc > > > > implementations, namely uClibc, Dietlibc and Newlib? > > > > > > Your patches are welcome. > > > > > > I thought that best way to handle other libc's is introducing other > > > 'architectures', like i386-uclibc. Then tools could just cross-compile > > > for this 'architecture'. > > > > Yes, that's what I did. Please look into 'patches' at > > http://www.xs4all.nl/~kurzanov/debian/. I had to patch dpkg, as well > > as dpkg-cross to make it all work. > > Thanks, I'll look at that. > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
