Hi, Quoting Emmanuel Bourg (2015-06-04 10:45:57) > Thank you for the detailed analysis Johannes. I removed the libmx4j-java > dependency on jetty, is it any better now?
removing dependencies (or moving them to recommends) always helps at least a little bit, yes. But the question is whether the effort of doing the removal (at a possible cost of convenience for the user installing the package with less dependencies or features) warrants the result. If by removing "the libmx4j-java dependency on jetty" you mean removing the dependency of the binary package libmx4j-java on libjetty-java, then the effect is only a very little one. Here is the smallest path after a removal of that dependency: https://mister-muffin.de/p/QI7u.png As explained in my other email, these kind of graphs are *not* suitable for for a human to find which dependencies to remove or which build-dependencies to mark with a build profile. This is only one of many shortest paths and removing one shortest path still leaves many others. The reason why the page http://bootstrap.debian.net/essential.html does not display why a given package is in the transitive essential set is because that information would either be an incredibly big and impossible to visualize graph or not be suitable to decide for an action. I generated the shortest path for the jython case because we were curious about the "why" but the graph cannot serve other purposes than to satisfy our curiosity. And this does not even mention that apart from the shortest paths between build-essential and jython there are also many paths longer than that. And then there is the fact that we are far away from doing bootstraps that assume that Architecture:all packages are not available. I think any optimization of dependencies in that direction at this point would be premature. Even if I would ask botch now what the best cut(s) would be to remove jython from the transitive essential set, the answer would probably be a different one in one or two releases in the future (in case bootstrapping including Architecture:all package becomes relevant by then) because many dependencies will have changed until then. Thanks! cheers, josch
signature.asc
Description: signature
