From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Colin Walters <walters@verbum.org>
Cc: poky@yoctoproject.org,
openembedded-core <openembedded-core@lists.openembedded.org>
Subject: Re: [poky] -dev RPM packages Require:ing all of their bitbake build dependences
Date: Wed, 04 Jan 2012 16:23:14 +0000 [thread overview]
Message-ID: <1325694194.20759.23.camel@ted> (raw)
In-Reply-To: <1325642890.24646.8.camel@lenny>
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
WARNING: multiple messages have this Message-ID (diff)
From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Colin Walters <walters@verbum.org>
Cc: poky@yoctoproject.org,
openembedded-core <openembedded-core@lists.openembedded.org>
Subject: Re: -dev RPM packages Require:ing all of their bitbake build dependences
Date: Wed, 04 Jan 2012 16:23:14 +0000 [thread overview]
Message-ID: <1325694194.20759.23.camel@ted> (raw)
In-Reply-To: <1325642890.24646.8.camel@lenny>
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
next prev parent reply other threads:[~2012-01-04 16:30 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-04 2:08 -dev RPM packages Require:ing all of their bitbake build dependences Colin Walters
2012-01-04 2:13 ` Colin Walters
2012-01-04 16:23 ` Richard Purdie [this message]
2012-01-04 16:23 ` Richard Purdie
2012-01-04 16:34 ` [poky] " Chris Larson
2012-01-04 16:34 ` [OE-core] " Chris Larson
2012-01-04 16:40 ` [poky] " Mark Hatle
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1325694194.20759.23.camel@ted \
--to=richard.purdie@linuxfoundation.org \
--cc=openembedded-core@lists.openembedded.org \
--cc=poky@yoctoproject.org \
--cc=walters@verbum.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.