On Thu, 2015-11-05 at 18:30 +0000, Tiago Gomes wrote:
I was just stating that there wouldn't be advantages of having
runtime-depends for this particular case. Like you said below, it
wouldn't achieve 100% efficiency.
TBH, I don't care much about how runtime-dependencies would be handled.
As Richard says :
> We can either include runtime dependencies of artifacts we build-depend
> on, or leave runtime dependencies to being purely for system artifact
> construction time.
> There's arguments for either.
> It makes some amount of sense for runtime dependencies of an artifact
> you build-depend on to be included in the staging area, as it saves
> having to define these build-only-runtime-depends as build-depends,
> which would cause unnecessary build-time dependencies for python modules.
> However, if you don't include this, then you only need to rebuild the
> system artifact when build-dependencies change, which has some appeal.
> The important thing is that you don't depend on _your_ runtime
> dependencies at build-time, but people who depend on you end up depending
> on _your_ runtime dependencies.
> This is sufficiently odd that it bakes my noodle a little.
First, please make sure that you note here that Richard's definition of
runtime dependencies is not the same as my definition, this was
clarified elsewhere in this thread.
Using the same words I used in another message:
A runtime dependency is the dependency on a chunk which need not be
built or added to the staging area in order to build the depending
Lets call Richard's alternative definition "install dependencies", I
dont really care what they are called right now but it's better to keep
our definitions separate for the sake of conversation.
Now, note that the complexity which results in the baking of noodles is
pretty much due to an attempt of handling install dependencies and
runtime dependencies in the same dependency graph - the whole picture
becomes more clear if you treat the build phase and the distribution
phase as entirely separate problem spaces.
In my last reply to you; I mentioned that I would much prefer using a
hybrid solution of Richards runtime dependency proposal (or any other
solution) for the purpose of slimming down and choosing what gets
included into a System, after the build phase is complete.
Using an install dependency graph which is orthogonal to the build
dependency graph (or perhaps built on *top* of the build dependency
graph as a fallback), would be an elegant way of handling the System
assembly problem in the distribution phase - a problem which is
intentionally left unsolved by this proposal.
> My feeling is that build time and runtime dependency declarations at the
> chunk level is the right balance of efficiency vs complexity.
> Further elaboration in the definitions to declare these dependencies at
> the artifact level instead of the chunk level would bring us closer to
> 100% efficiency (without making the reality of circular dependencies
> disappear) - however that 100% efficiency comes at an unreasonably high
> cost of complexity on all sides. Implementors would be left with a much
> more complex format to digest, and more importantly, users would be left
> with a much more complex and error prone definitions format.
> Does this sound reasonable to you ?
Why do you think that it would be more complex for the user? The
definitions wouldn't differ from the model that you proposed, it is just
how the runtime depends on a staging area are handled. Again, I am not
advocating one way or another.
To paint a picture:
When I originally started brewing this idea, over a month ago, I thought
of various dependency "types". Build time vs Runtime dependencies, and
also Hard vs Soft (optional) dependencies.
Then, I quickly realized that; if we were account for Soft vs Hard
dependencies in our formalism; we would need to provide a separate build
recipe for each possible combination of Soft dependencies that a chunk
The Flavors (or Variants) approach cuts this exponential complexity off
at the stem, as "every possible configuration" is pointless, we only
care about the variants which are useful for the systems we support and
The reason that I bring this up, is that treating dependencies for the
build phase at the artifact level brings this exponential complexity
Remember that for every given chunk, there are at the very least three
resulting artifacts (this is not implemented everywhere *yet*, but to
solve the distribution problem it will have to be).
One "base" artifact, one "dev" artifact and one "docs"
there are 4 artifacts for most chunks if you split out "locale", and
then you can also have more exotic chunks which split their artifacts in
other exotic ways.
Now, obviously we start having different dependency sets, and
consequently different build recipes for every possible way we could
build a given chunk. If we want to build docs, we require gtk-doc-utils
and we have to pass --enable-gtk-doc to ./configure. If we dont want to
build locale data we need to pass --disable-nls to ./configure and maybe
we dont require intltool.
Add flavors/variants to the mix, and you need one recipe for each
artifact of each variant of each chunk.
You cannot escape this; if you want artifact level dependencies to be
considered during the build phase, you need build recipes for each of
This is why; build dependencies and runtime dependencies are only
treated at the chunk level, and are only relevant for the build phase.
As a rule, you cannot "only build the artifacts you require for your
system"; if your system does not require the docs artifacts; you must
still build the docs artifacts for each chunk that you build.
After everything is built, you can then proceed to pick and choose which
artifacts of which chunks you mean to include in the system; possibly
using a simple manifest at the system level, or, possibly by
implementing a separate and build-orthogonal "install dependency" graph
explicitly for that purpose.
Make sense ?