use centrality/distance in graph

write script for bisecting Packages/Sources from snapshot.debian.org for changes in main scc and also compare different dists

try different external solver

reduced build dependencies can also be used to bootstrap languages

source packages that were cross compiled must be recompiled natively

during graph analysis:
  provide a way to mark build dependencies as non-breakable even in source
  packages without a build profile

when building a source package with a build profile, it might not generate some binary packages
which are otherwise needed in the same SCC. In this case, both versions of the source package must
be part of the SCC.

Package A and B provide C. A source package build depends on C. Its
installation set contains B. When calculating the intersection of each
disjunction with the installation set, how can one be sure that the package
that was chosen to provide C was indeed B and not A?

allow other libraries to use code of botch

find a way to combine order1.lst and order2.lst

investigate why the main SCC is smaller if calculating a self contained repo first

add a subgraph inside installation set nodes such that one can check how one gets from the binary package of the installation set to the binary package that builds from one of the connected source packages

create an importance metric for the cross case as well

allow an external list to be fed to cross.sh which contains information about which packages can and cannot be cross compiled
botch has to find a solution for cross compilation with only those packages that can be cross compiled

the loop in cross.sh does not take into account that the order of packages might change

make all output sorted

let dose2html also read the results from a native dose-builddebcheck run and mark those cases, where the native case also fails

fix-cross-problems cannot fix some problems. Some conflicts cannot be solved by making packages m-a:same

maybe add labels to buildgraph and srcgraph edges. The label for buildsfrom edges would be the "binaries" attribute. For builddep edges, this could be the Debian vpgks that lead to the InstSet vertex. Problem: At the point these Debian vpkgs can be added in BootstrapCommon.partition_deps, only the Cudf encoding of the packages is known and not the original Debian.Source package. Thus, only the edge could only be annotated with the cudf vpkg and not the Debian vpkg which is suboptimal and probably not very useful.

bash autocomplete
