Re: Cross compiler ITP (armel)
Neil Williams <codehelp@debian.org> writes:
> On Wed, 04 Nov 2009 15:11:06 +0100
> Goswin von Brederlow <goswin-v-b@web.de> wrote:
>
>> > As mentioned off-list, I disagree strongly. sysroot - as it
>> > appears at the moment - retains the hacks in dpkg-cross which means that
>> > cross-building anything more complex than a trivial rootfs becomes
>> > impossible. Cross-building needs to stop requiring package hacks,
>> > package renaming, version string hacks and the consequent complicated
>> > changes to the dependency chain.
>>
>> To be fair that doesn't help NOW.
>
> Of course, but 'now' is stuck in a dead end. Please accept that the
> dpkg-cross/apt-cross hacks are a complete dead end. Sometimes it is
> best to abandon one direction and start afresh. I maintained the
> existing hacks and wrote quite a few of my own to get the system to the
> point where we could have Emdebian Crush 1.0 - I can honestly say that
> I believe there is no "now" for dpkg-cross/apt-cross methods.
>
> If the RFH for apt-cross does not result in any new work, I'm
> considering turning it into an RM: before the Squeeze freeze - I'll
> almost certainly be turning the RFH into an O: unless someone comes
> forth.
I was at a point in ia32-apt-get where I was starting to obsolete
apt-cross, i.e. support for any arch and not just i386 on amd64. But
ftp-master removed ia32-apt-get.
So even if I (or someone else) step up and improve apt-cross that will
just end up in the same place as ia32-apt-get was and get the same
silent removal ia32-apt-get did. Doesn't really make me want to help.
>> While I agree cross-building should
>> use the multi-arch directories that will be in preparation of
>> multi-arch becoming a reality. Until such a time dpkg-cross/apt-cross
>> still need to do the renaming hacks. But all those hacks are well
>> understood and existing.
>>
>> So what I'm suggesting is doing it with hcks now in such a way that
>> multiarch will remove the remaining hacks when it becomes reality.
>
> I'm not sure what is gained by putting more work into a broken system.
>
> apt-cross is dead, if I hadn't nailed it to ftpmaster it'd be pushing
> up the daisies already. It's not so much gone to meet it's maker, it's
> been given up for dead by it's author!
>
> $ perl -e 'print "parrot\n" if ($apt-cross =~ "/Norwegian blue/");'
> $ parrot
>
> (apologies to Mr's Palin & Cleese.)
>
>> Well, ia32-apt-get did it just fine and all automatic. There also was
>> no foreign package with changed name in the archive but the original
>> foreign package was used. But none the less the converted foreign
>> package had the right "Source: <source> (version)" information giving
>> a clear correlation between the converted package and the source it
>> was build from. Also in any kind of transition the source
>> transitions. That means both the native and foreign package change
>> their source and therefore binary version. They are always both
>> updated and transitioned together. As for forcing both the native and
>> foreign package to be upgraded by the user as pair that is a simple
>> Depends. So that really isn't a problem. It is just a matter of
>> getting the information at the proper place.
>>
>> The usage is verry simple with ia32-apt-get:
>>
>> ia32-apt-get update
>> ia32-apt-get [dist-]upgrade
>>
>> Or with "ln -s /usr/share/ia32-apt-get/* /usr/local/bin" you can even
>> save the ia32- prefix. Get your apt-cross to be equaly user friendly.
>
> apt-cross cannot support this kind of action, it would need a complete
> rewrite. I certainly do not have time to consider any such effort.
And I would need ftp-masters assurance they won't just silently remove
it before considering working on it.
>> > The problems are outlined in #502433. The dependency calculations need
>> > to take account of what is already installed as foreign without native
>> > versions being considered, yet still take account of Arch:all - AFAICT
>> > multiarch allows this mode. For it to work, the package actually
>> > installed has to retain a correlation to what is in the Packages file,
>> > so that the correct dependency chain can be constructed. Changing
>> > package names (or even version strings due to strict versioned
>> > dependencies) in such situations is only going to lead to
>> > non-installable combinations, as we have now.
>>
>> ia32-apt-get does this by changing the Packages files post download
>> and only renaming packages that need to be foreign. There is
>> absolutely no reason the same renaming can not be applied to Sources
>> and control files for Build-Depends. That way anything (like apt,
>> dpkg, sbuild) looking at the Packages, Sources or debian/control files
>> sees the correct dependency chain and will install exactly the same
>> packages with the renaming or with multiarch. And a normal
>> dpkg-checkbuilddeps would also detect missing or wrong packages just
>> like in the non-cross case.
>>
>> But what has that got to do with #502433?
>
> 502433 is about the inability to accurately use such hacks to get a
> clean dependency path from a clean chroot to a full libgtk2.0-dev build
> environment using foreign packages.
>
> If you hack around the package names, the careful work of dozens of
> maintainers is thrown at /dev/null. It's not surprising that things
> break as soon as you try something remotely complicated.
No. You only need to run the renaming over the debian/control file as
well. That causes any Build-Depends to the native libfoo-dev to become
one to the foreign libfoo-dev. And the foreign libfoo-dev would also
pull in the native libfoo-dev and libfoo. A while ago I tried that as
an exercise on 2 small sources and with CC="gcc -m32" and it worked
just fine. I see no reason it should be any different for
CC=arm-linux-gnu-gcc.
MfG
Goswin
Reply to: