From: Phil Blundell <philb@gnu.org>
To: Patches and discussions about the oe-core layer
<openembedded-core@lists.openembedded.org>
Subject: Re: [PATCH 5/5] update-alternatives: Add alternatives as a runtime provide
Date: Tue, 02 Aug 2011 14:46:42 +0100 [thread overview]
Message-ID: <1312292802.4325.33.camel@phil-desktop> (raw)
In-Reply-To: <d97dcf096a3a72a2a087b2dbbcdd74c853f7e940.1312243899.git.mark.hatle@windriver.com>
On Mon, 2011-08-01 at 19:17 -0500, Mark Hatle wrote:
> The following allows RPM to generate the SDK image, however without it
> we get a failure because the system has nothing that provides /bin/sh.
>
> Unfortunately the patch causes failures with ipk and deb packages because
> they can not have filenames within their RPROVIDES. I'm looking for some
> type of a resolution to the issue, the only thing I can think of is to
> add a way to manually add a FILERPROVIDE for the items. This will require
> changes to the way FILERPROVIDE is currently generated... but I'm not sure
> how we can automatically generate the FILERPROVIDE values without the use of
> python...
>
> Any suggestions?
It's never really been the intent that update-alternatives should put
the name of the link being provided into RPROVIDES. If you want to
solve the specific problem with /bin/sh then just adding RPROVIDES_${PN}
+= "virtual-bourne-shell" or something to bash and busybox is probably
the easiest way of doing that.
I wouldn't be entirely opposed to the concept of what you're proposing
here, though. Something like:
RPROVIDES_${PN} += "${@' '.join(map(lambda x:
legitimize_package_name("virtual-path-" + x), filter(lambda x: x != '',
[ d.getVar('ALTERNATIVE_LINK', True) or '' ] +
(d.getVar('ALTERNATIVE_LINKS', True) or '').split())))}"
might be what you want, perhaps. I'm not sure that the resulting
virtual names will be very pretty though.
p.
next prev parent reply other threads:[~2011-08-02 13:51 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-02 0:17 [PATCH 0/5] Fix the SDK generation Mark Hatle
2011-08-02 0:17 ` [PATCH 1/5] rootfs_rpm: Cleanup and minor bug fixes Mark Hatle
2011-08-02 0:17 ` [PATCH 2/5] bitbake.conf: Add SDK_PACKAGE_ARCHS Mark Hatle
2011-08-02 0:17 ` [PATCH 3/5] populate_sdk_*: Sync SDK and regular rootfs functions Mark Hatle
2011-08-02 0:17 ` [PATCH 4/5] package_ipk: SDK generation workaround Mark Hatle
2011-08-02 0:17 ` [PATCH 5/5] update-alternatives: Add alternatives as a runtime provide Mark Hatle
2011-08-02 13:46 ` Phil Blundell [this message]
2011-08-02 14:49 ` Mark Hatle
2011-08-03 12:20 ` Richard Purdie
2011-08-03 14:41 ` Mark Hatle
2011-08-03 15:40 ` Richard Purdie
2011-08-03 16:03 ` Mark Hatle
2011-08-03 16:09 ` Richard Purdie
2011-08-02 13:34 ` [PATCH 0/5] Fix the SDK generation Richard Purdie
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=1312292802.4325.33.camel@phil-desktop \
--to=philb@gnu.org \
--cc=openembedded-core@lists.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox