Summary: | sys-apps/lshw is missing build dependencies | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | André Malo <nd> |
Component: | New packages | Assignee: | Gentoo's Team for Core System packages <base-system> |
Status: | VERIFIED FIXED | ||
Severity: | normal | ||
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | All | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | Patch against lshw-02.15b.ebuild |
Description
André Malo
2011-03-01 20:39:55 UTC
Created attachment 264303 [details, diff]
Patch against lshw-02.15b.ebuild
i see no indication that either of those proto packages are needed. the pc and header files they install do not seem to be used by lshw. ive added the pkgconfig dep only: http://sources.gentoo.org/sys-apps/lshw/lshw-02.15b.ebuild?r1=1.3&r2=1.4 Hmm, it dies here in the src/gui Makefile when calling pkg-config gtk+-2.0 --cflags when calling directly on the shell it looks like: gui # pkg-config gtk+-2.0 --cflags Package dri2proto was not found in the pkg-config search path. Perhaps you should add the directory containing `dri2proto.pc' to the PKG_CONFIG_PATH environment variable Package 'dri2proto', required by 'egl', not found (after installing dri2proto it misses glproto, after installing that it works) x11-libs/gtk+-2.22.1-r1[cups jpeg tiff xinerama] is installed. Do you need any more information? you're stepping into a gray area. those are *gtk* dependencies, not lshw. we do not list dependencies of dependencies in packages. *scratchinghead* so this is not fixed, but a WONTFIX. Grey area or not - it does not build without those deps. uh, no. by your logic, every single package in the tree that depends on gtk+ must also depend on every proto package that gtk+ depends on. you can obviously see how that makes absolutely no sense. what you're actually complaining about is the lack of BDEPEND. there are other bugs which track this issue. for now, stop unmerging random proto packages from your system. Yes, that actually makes sense, because it doesn't build otherwise. Calling a package with unresolved deps "fixed" is... well... strange, but not my decision. I've tried my best to be honest ;-) About BDEPEND - I thought DEPEND specifies build dependencies (and RDEPEND runtime deps). What would be the difference between DEPEND and BDEPEND? Can you point me to some document about that? (about unmerging "random" packages - depclean does this for me. Maybe the --with-bdeps option should be removed then) (In reply to comment #7) > Yes, that actually makes sense, because it doesn't build otherwise. Calling a > package with unresolved deps "fixed" is... well... strange, but not my > decision. I've tried my best to be honest ;-) > > About BDEPEND - I thought DEPEND specifies build dependencies (and RDEPEND > runtime deps). What would be the difference between DEPEND and BDEPEND? Can you > point me to some document about that? > > (about unmerging "random" packages - depclean does this for me. Maybe the > --with-bdeps option should be removed then) > Rant in bug 342393 instead, not here. (In reply to comment #8) > Rant in bug 342393 instead, not here. When I'm going to rant, I'll do that where it belongs. But thanks for the insight. Someone care to answer my question though? |