All of lore.kernel.org
 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 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.