Re: Questions regarding armhf port for Raspberry Pi
I'm glad you are optimistic about this as it encourages me. Before turning in last night I used the 'debtree' tool on a simple package like 'sed' and it produced a hideously complex tree of build dependencies. I didn't get a chance to understand exactly why the dependency tree was so complex, but I'll tackle that today. Perhaps debtree isn't the tool to be using, or at least a better set of options need to be selected.
On Fri, Mar 23, 2012 at 3:21 AM, Wookey <email@example.com>
True - but is there any static linking going on in fact? There isn't
much of it about these days (flex does it IIRC, and no doubt a few
other bits of software for various reasons). I have often wondered how
much 'old code' seeps through in a project like this. In theory it
should be very little. I've never checked the practice.
I simply don't know one way or the other. When dealing with unknowns I tend to assume the worst, just to be safe. :-)
That would require there not to be lots of circular build-dependencies
in Debian, such that there was a linear order to build things in.
That's not actually the case (see
http://wiki.debian.org/CircularBuildDependencies). In practice simply
building everything twice will probably do the trick.
Yes. I'm beginning to understand that. I've been reading the following document as I'm clearly going to need to fully understand these issues further to be successful.
The set of packages you install and the set of packages linked-against
will be the same, except for static linking, and I beleive that to be
very rare, quite possibly non-existent in a base install. So I don't
think this issue meaningfully changes your problem-size.
My primary experience with building systems was with FreeBSD about 10 years ago where I oversaw the building of all sources that went into a server farm. If I recall correctly, we hand built every piece of code from the kernel on up from sources before it was installed into the server farm. The BSD ports system was somehow constructed in a way to avoided circular dependencies (at least I don't recall running into the issue during builds). The fact we ran minimally configured systems on production servers probably helped.
Building everything twice does seem to be the standard way of dealing with such issues. I'll think though this a bit more and see hopefully that will be the answer as it limits the scope of the issue quite a bit.
BTW, other than armel and armhf which had to be bootstrapped, are there other instances of sub-arch flavors of Debian ARM being created recently? Getting ahold of build notes from those processes would help me a lot. I simply don't know enough yet to even know where to look for such documentation.