[OE-core] [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