From: Robert Yang <liezhi.yang@windriver.com>
To: Patches and discussions about the oe-core layer
<openembedded-core@lists.openembedded.org>
Cc: Koen Kooi <koen@dominion.thruhere.net>, Zhenfeng.Zhao@windriver.com
Subject: Re: [PATCH 2/3] ipk: install external binary packages
Date: Thu, 16 Aug 2012 19:18:30 +0800 [thread overview]
Message-ID: <502CD706.8050703@windriver.com> (raw)
In-Reply-To: <C2485FB5-A9C5-4CC5-8115-6ED44ED65468@dominion.thruhere.net>
On 08/16/2012 05:40 PM, Koen Kooi wrote:
>
> Op 16 aug. 2012, om 10:27 heeft Robert Yang <liezhi.yang@windriver.com> het volgende geschreven:
>
>> It's been suggested that it would be a useful feature to be able to
>> easily take a binary from a 3rd party software vendor and integrate
>> it into an image created by the build system.
>
> So why not write a recipe for such packages? That way you can fix a lot more of packaging screwups (it's a vendor binary, screwups are a given) and don't need to patch a ton of classes.
>
I think that this is easier than use recipe for such packages, here are my
rough thoughts:
If we do it in a recipe, we should tell the recipe:
1) Where are the binary pkgs
2) Which recipe will be installed
These 2 are similar to EXTERNAL_PACKAGE_DIR and EXTERNAL_INSTALL_PACKAGE which
I have used.
3) Write the do_fetch to copy the pkgs to $WORKDIR
4) Write the do_install to uncompress the binary pkgs if we want to fix the
screwups (I don't know the exactly meaning of screwups, I think it is
similar to "trouble"), and I don't know what can we fix for a binary pkg,
the common errors that we meet are the dependencies and conflicts, but it
seems that we can do nothing on them. If we can't fix the pkg, it seems not
very different from patch the class.
And from the user side, he needs to add the recipe to the image, then
specify where are the binary pkgs and which needs to be installed. It is not
as easy as the current implementation.
// Robert
_______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
>
next prev parent reply other threads:[~2012-08-16 11:30 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-16 8:27 [PATCH 0/3 V2] Install external binary packages Robert Yang
2012-08-16 8:27 ` [PATCH 1/3] rpm: install " Robert Yang
2012-08-18 16:55 ` Richard Purdie
2012-08-20 2:06 ` Robert Yang
2012-08-16 8:27 ` [PATCH 2/3] ipk: " Robert Yang
2012-08-16 9:40 ` Koen Kooi
2012-08-16 11:18 ` Robert Yang [this message]
2012-08-16 8:27 ` [PATCH 3/3] deb: " Robert Yang
2012-08-16 13:35 ` [PATCH 0/3 V2] Install " Robert Yang
-- strict thread matches above, loose matches on Subject: below --
2012-08-15 15:32 [PATCH 0/3] " Robert Yang
2012-08-15 15:32 ` [PATCH 2/3] ipk: install " Robert Yang
2012-08-16 8:03 ` Koen Kooi
2012-08-16 8:11 ` Robert Yang
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=502CD706.8050703@windriver.com \
--to=liezhi.yang@windriver.com \
--cc=Zhenfeng.Zhao@windriver.com \
--cc=koen@dominion.thruhere.net \
--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