Openembedded Core Discussions
 help / color / mirror / Atom feed
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.





  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