I was bored yesterday, so i have updated and re-run an old script i had
which tries to find ebuilds doing things like that:
DEPEND="foo? ( cat-bar/libfoo )"
src_compile() {
econf || die
emake || die
}
The problem here is that, if libfoo is installed, it will be linked to
even when USE=-foo, because the "foo" flag is not used to affect the
package configuration (no "$(use_enable foo)" or alike).
The heuristic behind my script is that when a USE flag is used in DEPEND
but is nowhere used in the ebuild code, there is something wrong. Sure,
this doesn't apply to RDEPEND, where optionnal runtime deps are very
welcome, and do not necessarily affect building of the package.
A run on yesterday's Portage tree has found 2027 occurences [1], in 1065
ebuilds [2] of 454 different packages [3]. Among the affected ebuilds,
367 were the best visible version of a package on ~x86 [4]. I've
thought some people might be interested by this results, hence this
email.
From this lists, i had 73 packages installed [5], that i have reviewed
[6] to see whether this results were complete crap or not. This analysis
indicates that the heuristic is not bad, and that implementation is not
as broken as i would have expected. Among the suspect conditionnal
DEPEND of this packages:
* 23 were actual automagic deps (what i was initialy after):
- 5 could be fixed by using some existing ./configure options
- 13 would need some autoconf patching (adding AC_ARG_ENABLE, etc.)
- 5 would need patching some other build system (not autotools)
* 40 were deps that should actually have been in RDEPEND only:
- 9 that are selinux policies
- 4 that are some extra gst-plugins
- 3 that are other dlopened or alike stuffs (which do not affect
the build time as far as i could see)
- 11 that are executables for the runtime (like CD-R writing or FS
formatting tools)
- 6 that are interpreted languages modules (that were not checked
or used at build-time sure)
- 7 that are data files (doc, fonts, etc.)
* 9 were useless deps (remainings of some older versions, doc-building
tools that are never called, etc.)
* 4 were false-positives:
- in lirc, because the script doesn't understand $LIRC_DEVICES
- in quake3, because the script missed the buildit() wrapper
around use()
- in pure-ftpd, because the script missed the enable_extension*()
from confutils.eclass
- in portage, because there is some "!build? ( ... )" deps
That's the only case i've found where the heuristic is at fault
on something legitimate. The 3 other false-positives are just
implementation issues of the script.
Now, the disclaimers:
- I am sure my review of the 73 ebuilds i had installed do contains
some mistakes. It was just a first pass to get a raw idea on the
heuristic itself and the amount of false-positives. Don't worry, i will
not go open 73 bug reports. Actually, i will only open some bug reports
for cases i find important (in particular, that doesn't include the 40
"should be RDEPEND"), as i find time to write the patches.
- If you look at the script [7,8], you will be horrified by how dumb
it is. Yes, it will both miss lots of true-positives, and report some
false-positive. It's not a static analyser for bash, but rather a stupid
piece of grepping which happens to point a fair number of ebuild issues.
[1]http://tdegreni.free.fr/gentoo/check_DEPEND_flags_usage/20070303/full-log.txt
[2]http://tdegreni.free.fr/gentoo/check_DEPEND_flags_usage/20070303/catpkgver-flags.txt
[3]http://tdegreni.free.fr/gentoo/check_DEPEND_flags_usage/20070303/catpkg.txt
[4]http://tdegreni.free.fr/gentoo/check_DEPEND_flags_usage/20070303/best_visible-full.txt
[5]http://tdegreni.free.fr/gentoo/check_DEPEND_flags_usage/20070303/installed-flags.txt
[6]http://tdegreni.free.fr/gentoo/check_DEPEND_flags_usage/20070303/installed-ebuilds-analysis.txt
[7]http://tdegreni.free.fr/gentoo/check_DEPEND_flags_usage/check_flags.sh
[8]http://tdegreni.free.fr/gentoo/check_DEPEND_flags_usage/check_flags_with_logs.sh
--
TGL.
--
gentoo-dev@gentoo.org mailing list
