[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: History of Debian bootstrapping/porting efforts

Since yesterday, my tools can now finally turn the whole dependency
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.

Reply to: