Re: Questions regarding armhf port for Raspberry Pi
On Fri, Mar 23, 2012 at 09:04:41AM -0700, Mike Thompson wrote:
> I simply don't know one way or the other. When dealing with unknowns I
> tend to assume the worst, just to be safe. :-)
> 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.
> 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.
> 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
A lot of circular depancies can actually be ignored if you only build
the binary packages and not the arch-all packages (documentation, etc).
Most circular dependancies seem to be tools used to generate documentation
needing a tool to compile them and that tool wants the documentation
generator to generate its documentation.
It would be great if build depends were seperated for building the
architecture specific stuff versus the other stuff so that you could
ignore all the documentation stuff initially. It would probably solve
90%+ of the circular build dependancies in Debian.