From: Richard Purdie <rpurdie@rpsys.net>
To: openembedded-devel@openembedded.org
Subject: Re: [RFC] Handling of virtual/* namespace in packages
Date: Mon, 15 Oct 2007 17:10:32 +0100 [thread overview]
Message-ID: <1192464632.25543.58.camel@localhost.localdomain> (raw)
In-Reply-To: <200710151419.07302.openembedded@haerwu.biz>
On Mon, 2007-10-15 at 14:19 +0200, Marcin Juszkiewicz wrote:
> In OpenedHand we got hit by virtual/update-alternatives and packaging.
> Poky contains two providers for virtual/u-a:
>
> 1. update-alternatives-cworth
> 2. update-alternatives-dpkg
>
> First one comes from IPKG source and is written in pure shell. Second one
> is in Perl so it fetch too much to be usable.
>
> The problem comes when you build both of them (it happens on our
> autobuilder due to 'world' build) - package manager (ipkg) selects random
> one - in our case it is always 'update-alternatives-dpkg' so generated
> rootfs is too big to be usable.
>
> Solution which came to my mind is quite simple. Our distro (Poky) already
> prefers 'u-a-cworth' as provider for 'virtual/update-alternatives'. So if
> package depends on 'virtual/update-alternatives' then let package.bbclass
> mangle its dependencies in such way that 'u-a-cworth' (preferred by
> distro) would be writen in package.
>
> What do you think about it?
I really liked this idea and I did some experiments but they had mixed
results. The problem is if we have:
RDEPENDS_${PN} = "virtual/xyz"
then bitbake gets upset as it can't work out what to build to fulfil
that.
We also need to avoid cross contaminating the DEPENDS and RDEPENDS
namespaces, they're separate and people *need* to think of them
separately.
I've started thinking of lots of perverse edge cases with the above too,
the problem is PREFERRED_PROVIDER is just a preference, not an absolute
and bitbake can ignore it to make a build work, especially in -k
(continue on failure) mode.
I was thinking we could have bitbake eject a set of variables:
VRPROVIDER_xyz = "abc"
VRPROVIDER_wxy = "bcd"
etc. which would tell us which provider bitbake was planning on using.
We could also adjust bitbake internals to cope with "virtual-runtime/"
variables in the RDEPENDS space but even that isn't going to be enough.
Consider:
PREFERRED_PROVIDER_virtual/xserver = "xserver-kdrive"
and bitbake setting:
VRPROVIDER_xserver = "xserver-kdrive"
None of this fixes the existing problem of how to get
"xserver-kdrive-fbdev" back and bitbake is always going to need help to
work that one out...
So perhaps we should just standardise the existing xserver behaviour
into a dedicated namespace:
DEPENDS = "virtual/xserver"
RDEPENDS_xyz = "${VIRTUAL-RUNTIME_xserver}"
and the machine.conf in this case would say
PREFERRED_PROVIDER_virtual/xserver = "xserver-kdrive"
VIRTUAL-RUNTIME_xserver = "xserver-kdrive-fbdev"
I'd love to find a nicer solution but I just can't come up with one that
will work...
Cheers,
Richard
next prev parent reply other threads:[~2007-10-15 16:17 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-10-15 12:19 [RFC] Handling of virtual/* namespace in packages Marcin Juszkiewicz
2007-10-15 14:35 ` pHilipp Zabel
2007-10-15 19:33 ` Richard Purdie
2007-10-15 14:53 ` Koen Kooi
2007-10-15 19:05 ` Richard Purdie
2007-10-15 16:10 ` Richard Purdie [this message]
2007-10-15 18:11 ` Koen Kooi
2007-10-15 20:06 ` Richard Purdie
2007-10-17 9:07 ` Koen Kooi
2007-10-17 10:47 ` Dr. Michael Lauer
2007-10-17 20:32 ` Koen Kooi
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=1192464632.25543.58.camel@localhost.localdomain \
--to=rpurdie@rpsys.net \
--cc=openembedded-devel@lists.openembedded.org \
--cc=openembedded-devel@openembedded.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.