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