-dev RPM packages Require:ing all of their bitbake build dependences

-dev RPM packages Require:ing all of their bitbake build dependences

[Colin Walters]

I'm trying to use Yocto to generate a target which has standard build
tools like gcc, make, the glibc headers etc.

In theory, this is solved by task-core-sdk, but I ran into the issue
that "pkg-config-dev" contains pkg.m4 which is obviously necessary for
building anything that uses pkg-config and the autotools.  The further
issue is that OE has a rule that -dev packages Require: all of the RPMs
used to build the recipie.

In the case of pkgconfig-dev, that pulls in libglib-2.0-dev which pulls
in libx11-dev which is already way more than I want.

One approach to this problem is to drain the -dev packages into the main
"runtime" package.  I have difficulty imagining someone wanting to
ship /usr/bin/pkg-config but not pkg.m4 for example.  I'm not yet sure
how many recipes are affected though.

Another approach would be to stop injecting -dev Requires by default.  I
imagine this was done to handle the case of library A whose headers
require library B.  However, a saner way to handle this I think is
simply to push people to use pkg-config; IIRC a script exists to extract
pkg-config dependencies from the .pc files and use that for the RPM
auto-dependency phase.  That would ensure that e.g. gtk+-dev Requires:
glib-dev.  This doesn't help non-pkg-config libraries, but those people
should be shamed anyways =)

Re: -dev RPM packages Require:ing all of their bitbake build dependences

[Colin Walters]

[-- Attachment #1: Type: text/plain, Size: 196 bytes --]

See example attached patch for pkg-config.

A question if we go down this path though - should e.g. the GCC plugin
header files by this rationale also be in the main package, and not
-dev?


[-- Attachment #2: 0001-pkgconfig-Include-pkg.m4-in-main-package.patch --]
[-- Type: text/x-patch, Size: 1331 bytes --]

From 1e94c2156c46eada940f7d50ae42cc0984e02237 Mon Sep 17 00:00:00 2001
From: Colin Walters <walters@verbum.org>
Date: Tue, 3 Jan 2012 21:11:03 -0500
Subject: [PATCH] pkgconfig: Include pkg.m4 in main package

Having it in -dev forces consumers to include the -dev package which
in turn pulls in libglib-2.0-dev which pulls in...

I can't imagine anyone wants /usr/bin/pkg-config without the .m4 file.
---
 meta/recipes-devtools/pkgconfig/pkgconfig.inc |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/meta/recipes-devtools/pkgconfig/pkgconfig.inc b/meta/recipes-devtools/pkgconfig/pkgconfig.inc
index 641bfae..37f6a90 100644
--- a/meta/recipes-devtools/pkgconfig/pkgconfig.inc
+++ b/meta/recipes-devtools/pkgconfig/pkgconfig.inc
@@ -25,6 +25,10 @@ EXTRA_OECONF = "--with-installed-glib --with-installed-popt --disable-legacy-scr
 EXTRA_OECONF_virtclass-native = "--disable-legacy-scripts"
 EXTRA_OECONF_virtclass-nativesdk = "--disable-legacy-scripts"
 
+# Include the .m4 in the main package - it's silly to have pkg-config without also
+# being able to run aclocal and use the PKG_CHECK_MODULES() macro.
+FILES_${PN} += "${datadir}/aclocal/pkg.m4"
+
 acpaths = "-I ."
 do_configure_prepend () {
 	install -m 0644 ${WORKDIR}/glibconfig-sysdefs.h glib-1.2.10/
-- 
1.7.6.4

Re: [poky] -dev RPM packages Require:ing all of their bitbake build dependences

[Richard Purdie]

On Tue, 2012-01-03 at 21:08 -0500, Colin Walters wrote:
> I'm trying to use Yocto to generate a target which has standard build
> tools like gcc, make, the glibc headers etc.
> 
> In theory, this is solved by task-core-sdk, but I ran into the issue
> that "pkg-config-dev" contains pkg.m4 which is obviously necessary for
> building anything that uses pkg-config and the autotools.  The further
> issue is that OE has a rule that -dev packages Require: all of the RPMs
> used to build the recipie.
> 
> In the case of pkgconfig-dev, that pulls in libglib-2.0-dev which pulls
> in libx11-dev which is already way more than I want.
> 
> One approach to this problem is to drain the -dev packages into the main
> "runtime" package.  I have difficulty imagining someone wanting to
> ship /usr/bin/pkg-config but not pkg.m4 for example.  I'm not yet sure
> how many recipes are affected though.

I can imagine someone downloading something and wanting to build it but
not reautoconf'ing it. At that point you'd need pkg-config but not
the .m4 files.

> Another approach would be to stop injecting -dev Requires by default.  I
> imagine this was done to handle the case of library A whose headers
> require library B.  However, a saner way to handle this I think is
> simply to push people to use pkg-config; IIRC a script exists to extract
> pkg-config dependencies from the .pc files and use that for the RPM
> auto-dependency phase.  That would ensure that e.g. gtk+-dev Requires:
> glib-dev.  This doesn't help non-pkg-config libraries, but those people
> should be shamed anyways =)

I think these dependencies are wrong and need revisiting. Currently,
-dev and -dbg packages share the same code and its tilted more in favour
of -dbg than it is for -dev.

I think the -dev packages make sense if you want to build X but not
build something that just depends on X. We should therefore move the
dependencies to a new package (need a good name) and rethink the -dev
package dependencies.

Cheers,

Richard

Re: -dev RPM packages Require:ing all of their bitbake build dependences

[Richard Purdie]

On Tue, 2012-01-03 at 21:08 -0500, Colin Walters wrote:
> I'm trying to use Yocto to generate a target which has standard build
> tools like gcc, make, the glibc headers etc.
> 
> In theory, this is solved by task-core-sdk, but I ran into the issue
> that "pkg-config-dev" contains pkg.m4 which is obviously necessary for
> building anything that uses pkg-config and the autotools.  The further
> issue is that OE has a rule that -dev packages Require: all of the RPMs
> used to build the recipie.
> 
> In the case of pkgconfig-dev, that pulls in libglib-2.0-dev which pulls
> in libx11-dev which is already way more than I want.
> 
> One approach to this problem is to drain the -dev packages into the main
> "runtime" package.  I have difficulty imagining someone wanting to
> ship /usr/bin/pkg-config but not pkg.m4 for example.  I'm not yet sure
> how many recipes are affected though.

I can imagine someone downloading something and wanting to build it but
not reautoconf'ing it. At that point you'd need pkg-config but not
the .m4 files.

> Another approach would be to stop injecting -dev Requires by default.  I
> imagine this was done to handle the case of library A whose headers
> require library B.  However, a saner way to handle this I think is
> simply to push people to use pkg-config; IIRC a script exists to extract
> pkg-config dependencies from the .pc files and use that for the RPM
> auto-dependency phase.  That would ensure that e.g. gtk+-dev Requires:
> glib-dev.  This doesn't help non-pkg-config libraries, but those people
> should be shamed anyways =)

I think these dependencies are wrong and need revisiting. Currently,
-dev and -dbg packages share the same code and its tilted more in favour
of -dbg than it is for -dev.

I think the -dev packages make sense if you want to build X but not
build something that just depends on X. We should therefore move the
dependencies to a new package (need a good name) and rethink the -dev
package dependencies.

Cheers,

Richard

Re: [poky] -dev RPM packages Require:ing all of their bitbake build dependences

[Chris Larson]

On Wed, Jan 4, 2012 at 9:23 AM, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
>> Another approach would be to stop injecting -dev Requires by default.  I
>> imagine this was done to handle the case of library A whose headers
>> require library B.  However, a saner way to handle this I think is
>> simply to push people to use pkg-config; IIRC a script exists to extract
>> pkg-config dependencies from the .pc files and use that for the RPM
>> auto-dependency phase.  That would ensure that e.g. gtk+-dev Requires:
>> glib-dev.  This doesn't help non-pkg-config libraries, but those people
>> should be shamed anyways =)
>
> I think these dependencies are wrong and need revisiting. Currently,
> -dev and -dbg packages share the same code and its tilted more in favour
> of -dbg than it is for -dev.
>
> I think the -dev packages make sense if you want to build X but not
> build something that just depends on X. We should therefore move the
> dependencies to a new package (need a good name) and rethink the -dev
> package dependencies.


I'm inclined to say let the user install the deps needed to build X
themselves, or build it with bitbake, and let -dev work the way it
does in other distros, the bits needed to build against X.
-- 
Christopher Larson

Re: [OE-core] -dev RPM packages Require:ing all of their bitbake build dependences

[Chris Larson]

On Wed, Jan 4, 2012 at 9:23 AM, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
>> Another approach would be to stop injecting -dev Requires by default.  I
>> imagine this was done to handle the case of library A whose headers
>> require library B.  However, a saner way to handle this I think is
>> simply to push people to use pkg-config; IIRC a script exists to extract
>> pkg-config dependencies from the .pc files and use that for the RPM
>> auto-dependency phase.  That would ensure that e.g. gtk+-dev Requires:
>> glib-dev.  This doesn't help non-pkg-config libraries, but those people
>> should be shamed anyways =)
>
> I think these dependencies are wrong and need revisiting. Currently,
> -dev and -dbg packages share the same code and its tilted more in favour
> of -dbg than it is for -dev.
>
> I think the -dev packages make sense if you want to build X but not
> build something that just depends on X. We should therefore move the
> dependencies to a new package (need a good name) and rethink the -dev
> package dependencies.


I'm inclined to say let the user install the deps needed to build X
themselves, or build it with bitbake, and let -dev work the way it
does in other distros, the bits needed to build against X.
-- 
Christopher Larson

Re: [poky] -dev RPM packages Require:ing all of their bitbake build dependences

[Mark Hatle]

On 1/4/12 10:34 AM, Chris Larson wrote:
> On Wed, Jan 4, 2012 at 9:23 AM, Richard Purdie
> <richard.purdie@linuxfoundation.org>  wrote:
>>> Another approach would be to stop injecting -dev Requires by default.  I
>>> imagine this was done to handle the case of library A whose headers
>>> require library B.  However, a saner way to handle this I think is
>>> simply to push people to use pkg-config; IIRC a script exists to extract
>>> pkg-config dependencies from the .pc files and use that for the RPM
>>> auto-dependency phase.  That would ensure that e.g. gtk+-dev Requires:
>>> glib-dev.  This doesn't help non-pkg-config libraries, but those people
>>> should be shamed anyways =)
>>
>> I think these dependencies are wrong and need revisiting. Currently,
>> -dev and -dbg packages share the same code and its tilted more in favour
>> of -dbg than it is for -dev.
>>
>> I think the -dev packages make sense if you want to build X but not
>> build something that just depends on X. We should therefore move the
>> dependencies to a new package (need a good name) and rethink the -dev
>> package dependencies.
>
>
> I'm inclined to say let the user install the deps needed to build X
> themselves, or build it with bitbake, and let -dev work the way it
> does in other distros, the bits needed to build against X.

Ya, that seems to be the best solution for a more modern system.

This will require a combination of additional automatic dependency detection and 
also manual intervention when that detection isn't complete.

The complications with the automatic detection are around the header files... 
we'll need to detect when one header includes another, and then translate that 
to an associated -dev file.  But I know there are intentionally broken includes 
(wrapped in #if's etc..)

--Mark