[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: possible MBF: automatically detecting unused build dependencies



Hi,

Quoting Maarten Lankhorst (2014-07-09 15:48:33)
> ==> llvm-toolchain-3.4_3.4.1-4.arch-all.unusedbd.real <==
> automake=1:1.14.1-3
> autotools-dev=20140510.1
> diffstat=1.58-1
> doxygen=1.8.7-1
> flex=2.5.39-7
> lcov=1.10-1
> libtool=2.4.2-1.7
> patchutils=0.3.3-1
> procps=1:3.3.9-5
> sharutils=1:4.14-2
> tcl=8.6.0+8
> texinfo=5.2.0.dfsg.1-3
> 
> No, building with DEB_BUILD_OPTIONS=codecoverage enables at least some of them,

should build dependencies which the source package only requires after setting
some DEB_BUILD_OPTIONS go into Build-Depends?

> and applying patches might require the autotools to be re-run, so I think
> lots of the requirements are sane.

My naive assumption was that the Build-Depends line contains a list of binary
packages needed to build the package. Not binary packages that might be needed
in some situations during the lifetime of a source package?

> doxygen is probably used for llvm-3.4-doc, so I think it might not be unused
> either.  texinfo probably the same.

The traces show that no file of the doxygen or texinfo package are run during a
normal build (including building architecture:all packages). You say they are
used. So maybe this indicates a bug where you think they should be used but are
in fact not? Could you make sure?

> diffutils, tcl, flex, patchutils, procps could possibly be unused, although
> not 100% sure. :-)

the only kind of false positive that was pointed out this method has is that it
discovers otherwise empty packages (meta packages) which depend on other
packages without which the build will nevertheless succeed because it will just
silently fail if the tools provided by them are found to not be present.

The package tcl is such a case and might thus be a false positive.

The other packages are containing actual usable content and should be
legitimate.

It would be great if you could point out if there was yet another undiscovered
flaw in my method.

Thank you!

cheers, josch


Reply to: