Re: possible MBF: automatically detecting unused build dependencies
Hi,
Quoting Steve Langasek (2014-07-07 20:22:42)
> Ah. No, it only means that the package build does not *fail* if the
> build-dependency is removed. That is not the same thing as saying that the
> build-dependency is not used.
>
> It would of course be better if packages were resilient against breakage in
> their build-dependencies, instead of misbuilding with features disabled or
> with wrong fallback code. But this isn't easy to do in all build systems,
> and anyway this isn't something we routinely audit about our packages; we
> shouldn't regard this as a bug to be reported without a lot more discussion
> of how we're going to systematically stay on top of those issues in the
> future.
>
> For your purposes, a better method would be:
>
> - identify those build-dependencies which are empty except for
> /usr/share/doc
> - for each such package, look at the contents of its direct dependencies
> - check the build against those contents
it turns out that 13% of my results are packages with no other content than in
/usr/share/doc. Namely:
libreadline-dev, default-jdk-doc, doxygen-latex, gcj-native-helper,
g++-multilib, gobjc, libboost-dev, libboost-system-dev, libgmp3-dev,
libgphoto2-2-dev, libopenais-dev, libtasn1-3-dev, libxmlrpc-c3-dev, lynx,
mysql-server, python3-all-dbg, python3-all-dev, libdb-dev, python-all,
python-gobject, python-all-dbg, python-all-dev
I'll re-run the whole caboodle later this year but consider the file content of
empty packages to be the sum of the content of packages it depends on. This
should reduce the number of this kind of false positives.
Do you think I should fill bugs for all non-empty packages that were already
found? Or do you think there is another high chance of false positives for that
kind of packages too?
cheers, josch
Reply to: