Re: Bootstrapping: list of 81 self-cycles in Debian Sid
Hi,
Quoting The Wanderer (2013-03-06 14:46:49)
> In that case, this (part of it) is a problem with my misunderstanding the
> terminology being used.
The terminology is based upon the dependency representation in the dependency
graph. We have two different types of graph, the source graph which only
contains source packages and the build graph which also contains binary package
nodes between source package nodes. My GSoC application contains a graphical
representation of the build graph:
http://wiki.debian.org/SummerOfCode2012/StudentApplications/JohannesSchauer
The term self-cycle is used in the same way as in any other graph and just
describes a self-edge: an edge which has the same start and end node.
Those self-cycles can only exist in the source graph. In the build graph
representation, self cycles are cycles of length two. If you look at the wiki
page I linked to earlier, then you will see that the smallest cycles are of
length two. This is because that wiki page and most of our work is based upon
the build graph.
> > This is the cycle that you took as an example earlier. So yes, we can also
> > find those cyclic dependencies but they are a different problem class
> > because instead of having just one way to break them, there are now two:
>
> Thank you.
>
> On the face of it this doesn't seem to address the question I was actually
> trying to ask (does this cycle-detection effort also detect "soft" dependencies
> which simply result in reduced functionality, as well as ones which result in
> build failures?), but the fact that this particular "soft" dependency is
> included in that - presumably automatically-generated - list implies that the
> answer is "yes".
No it doesnt. The software can only work on existing meta data. As of now,
there exist no meta data about which build dependencies of a debian source
package are droppable. That this cycle was detected does not mean that the
software knows that it can be dropped. The cycle is a syntactic property of the
dependency graph. For this cycle to exist it doesnt matter whether or not a
dependency is droppable in practice. The fact that the build dependencies of
the cycle in your example can be dropped in practice is pure luck.
If you know any way to automatically generate these "soft" dependencies, dont
hesitate to tell. Right now, those "soft" dependencies are supplied either
manually or were harvested from Gentoo USE flags. I wrote another email in this
thread about that topic.
cheers, josch
Reply to: