Since yesterday, my tools can now finally turn the whole dependency
graph
Does this "whole dependency graph" include the implicit build-dependency
every package has on build-essential?
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
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.
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.
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.
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.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/50aef1f4.6040...@p10link.net
