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 -- 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/20130306144410.26281.18657@hoothoot
