Does this "whole dependency graph" include the implicit build-dependency every package has on build-essential?Since yesterday, my tools can now finally turn the whole dependency graph
I don't see why it would be impossible to hack up the glib source package to not rely on pkg-config. Whether that is a good idea or not is another matter.The above case for example has no alternative solution as the cycle is of length two and has no other way of braking it than building pkg-config without libglib2.0-dev. Since this is unlikely to be possible
It seems pretty clear to me that there is a "core" of software that will need to be cross-built as the first stage of bootstrapping a port. Obviously "essential" and "build-essential" fall into this category but while i'm sure there are ways one could hack away the cycles and make things like pkg-config and debhelper natively bootstrapable I don't think there is much point in doing so.and since the assumption is that only build dependencies might be dropped when necessary but not binary dependencies, a possible solution might be cross compilation.
What i'd ideally like to see is for a tool to be able to generate a directed acyclic graph of "build jobs" (some cross, some native, there should be an option in the tool as to whether to preffer native or cross-build jobs) that takes the user from having no packages for the target architecture to having a set of bootstrap packages that can be used to seed the "regular" building process.