Re: AArch64 planning BoF at DebConf
On Fri, Jul 20, 2012 at 4:12 PM, Steve McIntyre <steve@einval.com> wrote:
> [ Please note the cross-post and Reply-To ]
noted :)
> I'm hoping to get AArch64 bootstrapped and ready for release in Debian
> by Wheezy+1, which I acknowledge will take a lot of work in a
> comparatively short space of time. We will need to cross-bootstrap as
> much as possible, verifying things in the model. Existing bootstrap
> work done by Wookey and co. will help a lot here.
*scratches head*... um... gah, this is awkward. where do i begin.
ok, cast your minds back to when, to begin the armhf port,
konstantinous was having a hell of a job getting beyond the circular
build dependencies (within even the core packages) that have crept
into the debian packaging. not the install dependencies of the core
packages, which are known to be circular, but the *build*
dependencies.
worst-case example: if you want to build a new version of a package,
you have to have the old one's header file package installed. but to
build that one, you need the previous... and so on, eventually getting
back possibly several *years* to a time when that circular build
dependency didn't exist, but of course the source code for those older
packages and *their* build dependencies could possibly now no longer
exist (especially if the cross-over point was isolated in between
debian major releases)
if you recall, i asked konstantinous if he could best document all of
the circular build dependencies that he had encountered, so that the
issues that he had encountered could be addressed, or the work-arounds
that he created could be duplicated in future, possibly in an
automated fashion. he declined to do so, unfortunately. also, a
number of people, if i recall, mentioned words to the effect of "new
architectures don't come along that often, so don't worry about it".
@begin awkward embarrassing moment, feel free to gloss over....
i also made some recommendations and offered to knock together a build
infrastructure which would have augmented the existing debian build
system, (which would have leveraged the best free software
cross-compiling and qemu-compile-enabled toolchain that there is, and
made it debian-aware) but the recommendations were, sadly, viewed as -
once again - "oo the fuck's this lkcl telling us what the fuck to do,
we've been doing this for years, oo der fuck does ee fink ee is,
trying to take over debian, let's vilify him, deliberately
misunderstand what he's saying as much as we can as often as we can,
make him look a fool so we look good and he'll go away ahhh that's
better: we can go back to doing it our way, now, and stay in control
yessss" rather than being viewed as what they were offered as: an
augmentation of and an enhancement of the existing debian build
system, offered *without* prejudice and entirely in good faith.
@end awkward moment.
*rueful*.
so, anyway. *shakes head to clear the air*.
here we are, only 18 months later, and there's *another* architecture
already on the horizon (*1)! whilst this is fantastic news, and very
very exciting, i really don't know whether to laugh or cry in sympathy
at the task ahead for the key debian developers, especially you,
wookey.
i just hope that there's some trick that can be pulled, here -
something like starting up with an arm64 kernel but running pure
32-bit packages, then being able compile one-by-one each package as
well as its 32-bit mapping in /usr/lib64, instead of having to do a
complete total laborious "everything-in-one-go" hacked-together
bootstrap like konstantinous had to.
i'm sure i saw a procedure somewhere, dating back to 2005, which
allowed a live 32-bit i386 debian system to be upgraded (without a
total reinstall!) live to an amd64 one, but... yeah, iii don't believe
it involved having to build every single amd64 package first :)
well - good luck: i'm rooting for ya! things are just moving so fast
in the ARM world, it's amazing.
l.
(*1) ... and what happens when there's an arm64 armv9 or armv10 or...
arm64-die-hard-with-a-vengeance-float, such that *another*
architecture is needed? what happens if the gnu/hurd team get some
resources together and want to do an arm-hurd *and* an arm64-hurd
architecture? what will it take to make the task of creating new
architectures that much easier than it is right now?
Reply to: