Bug#787562: jython FTBFS and jython is uninstallable because of unsatisfied (build-)dependency on libjnr-posix-java (>= 3.0.10~)

[Johannes Schauer]

Hi,

Quoting tony mancill (2015-06-03 15:38:02)
> However, I'd like to understand how jython figures into the transitive set
> (and why - maybe we get it out of the essential set), and how a developer can
> determine this.
> 
> [...]
> 
> So is there a tool I can use to view the entire tree to see where jython is
> required?

Yes. But unfortunately it is not a tree but a graph. And a very big one at
that.

I'm using the following pipe to get the shortest path from build-essential to
jython:

PACKAGES=/var/lib/apt/lists/http.debian.net_debian_dists_sid_main_binary-amd64_Packages
SOURCES=/var/lib/apt/lists/http.debian.net_debian_dists_sid_main_source_Sources
ARCH=amd64

	grep-dctrl --exact-match --field Package build-essential "$PACKAGES" \
		| botch-latest-version - - \
		| botch-bin2src --deb-native-arch="$ARCH" - "$SOURCES" \
		| botch-create-graph --verbose --progress --deb-native-arch="$ARCH" --strongtype --bg "$SOURCES" "$PACKAGES" - \
		| botch-graph-shortest-path --source type:bin name:build-essential --target type:src name:jython \
		| botch-graphml2dot > jython.dot

The result is a dot file which you can then either look at in xdot:

	xdot jython.dot

Or render to an image:

	dot -Tpng jython.dot > jython.png

It looks like this:

	https://mister-muffin.de/p/eaC1.png

The above command takes very long (25 minutes on my machine) to execute because
of the botch-create-graph step. There is currently no way to restrict the
calculation of the dependency graph to the set of vertices connecting two
desired vertices so instead, the entire graph is calculated. It would be
possible to reduce the graph size using other means but I chose above version
as it uses fewer commands and works using just a single pipe with no temporary
files and is thus less confusing (at the cost of longer runtime). Here is a
version with more commands which only takes 10 minutes:

	grep-dctrl --exact-match --field Package build-essential "$PACKAGES" \
		| botch-latest-version - - \
		| botch-bin2src --deb-native-arch="$ARCH" - "$SOURCES" \
		| botch-create-graph --verbose --progress --deb-native-arch="$ARCH" --closuretype --bg "$SOURCES" "$PACKAGES" - \
		| botch-buildgraph2packages - "$PACKAGES" \
		| botch-bin2src --all --deb-native-arch="$ARCH" - "$SOURCES" \
		| botch-create-graph --verbose --progress --deb-native-arch="$ARCH" --strongtype "$PACKAGES" - \
		| botch-graph-shortest-path --source type:bin name:build-essential --target type:src name:jython \
		| botch-graphml2dot > jython.dot

It's possible to make this even faster but then it starts requiring temporary
files.

It is also possible to show *all* paths between two vertices (and not only the
shortest one) but this would make the graph too big for easy viewing (several
thousand vertices and several ten-thousand edges), so here I chose to just show
one of the (there are a few hundred) shortest paths from build-essential to
jython.

As you can see in above graph rendering, one of the shortest paths from
build-essential to src:jython is:

build-essential -> src:gcc-5 -> libcairo2-dev -> src:x11proto-core -> fop ->
src:libxalan2-java -> libbcel-java -> src:bcel -> libmaven-javadoc-plugin-java
-> src:jetty -> libmx4j-java -> src:libmx4j-java -> jython -> src:jython

You will see that some binary packages in round ellipses point to source
packages that they do not build from. This is because the ellipses do not
represent single binary packages but whole installation sets. Expanding all the
ellipse vertices to their full binary paths would again let the graph size
explode and make it close to impossible to understand the graph.

You also see that there are several Architecture:all packages inside. During a
normal bootstrap of a new architecture, all Architecture:all packages already
exist and do not need to be bootstrapped again. But there is another bootstrap
scenario: the one where one bootstraps build-essential for reproducibility,
security and trust reasons. In that case, no dependency of build-essential,
including Architecture:all must come from another source.

So no worries, jython does not get into the way of practical Debian
bootstrapping for new architectures :)

Also, the different transitive essential sets are generated regularly here:
http://bootstrap.debian.net/essential.html

cheers, josch
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-java-maintainers/attachments/20150604/d4334625/attachment-0001.sig>