On Wed, Aug 29, 2012 at 6:14 PM, Michał Górny wrote: > On Wed, 29 Aug 2012 18:05:19 -0400 Mike Frysinger wrote: >> On Wed, Aug 29, 2012 at 6:02 PM, Michał Górny wrote: >> > On Wed, 29 Aug 2012 17:50:16 -0400 Mike Frysinger wrote: >> >> On Wed, Aug 29, 2012 at 5:42 PM, Michał Górny wrote: >> >> > In other words, pkg-config is only used when no other criteria >> >> > allows it to classify the particular .la file as suitable for >> >> > removal or not. Sadly, it's rather, ehm, unfriendly to ebuild >> >> > developers who obviously don't even read the relevant part. >> >> > >> >> > Do you have any ideas how we can improve that? >> >> >> >> before the func executes pkg-config, run `has virtual/pkgconfig >> >> ${DEPEND}` and spit an eqawarn if it's not found >> > >> > Ciaran will shot at me for doing that. >> >> it isn't violating anything and can find real bugs. i don't see a >> problem here. > > It is violating the Holy PMS.
does it actually ? are DEPEND variables not allowed to be expanded in pkg_* src_* funcs ? we could probably add a similar check to autotools.eclass: grep for PKG_PROG_PKG_CONFIG and check ${DEPEND} >> >> > One thing that comes into my mind is finally making pkgconfig >> >> > a required, implicit part of toolchain (or @system). Since we >> >> > have pkgconf now, this is more feasible than before. >> >> >> >> i don't think making it part of the toolchain makes sense. i'd >> >> rather not add it to @system simply to keep a few packages from >> >> sometimes failing. >> > >> > I'd add it to @system because a lot of packages actually need to >> > DEPEND on pkgconfig because they use libraries using .pc files. And >> > the number is going to increase, hopefully. >> >> sure, but keeping things in @system doesn't make much sense: >> - there's a penalty (as noted in old threads) >> - it isn't actually required at runtime, so it's bloat on reduced >> systems > > I think it's practically the same as compiler. that isn't a bad view point, but for the purposes of this discussion, i don't think it's relevant :) > Also, a quick look at !ddep shows over 7000 reverse dependencies. That > looks like a bigger penalty to me. if we had a @build-system, you might be able to convince me. but we don't. so the number of packages here doesn't matter as it's an invalid implicit RDEPEND. -mike