All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andre McCurdy <armccurdy@gmail.com>
To: Loic Poulain <loic.poulain@linaro.org>
Cc: OE Core mailing list <openembedded-core@lists.openembedded.org>
Subject: Re: Automatic prebuilt management
Date: Fri, 23 Aug 2019 11:11:22 -0700	[thread overview]
Message-ID: <CAJ86T=XwwjSZR6oNdXCr=bvbOKw5trKWJ=na4=_+83vXXJo6Bw@mail.gmail.com> (raw)
In-Reply-To: <CAMZdPi_2=mFZFgwzUVis4BE7P3C4boOZmVB6_eYeLCaT0wLJaA@mail.gmail.com>

On Mon, Aug 5, 2019 at 9:06 AM Loic Poulain <loic.poulain@linaro.org> wrote:
> Say a company works with an OE internal tree, with open-source and closed-source packages. The company wants to release the tree so that its customers can fully customize the images/distro. The closed sources being only available internally, the company has to generate and handle prebuilt binaries for proprietary packages. Ideally, with a unified public/internal OE tree (same recipes for internal/public build).
>
> This question is actually similar to an older thread:
> https://marc.info/?l=openembedded-core&m=146779329804683

That very old thread was also referenced recently in a follow up where
I shared a later solution, see:

  http://lists.openembedded.org/pipermail/openembedded-core/2019-July/284896.html

> I started to work on this and added a 'generate-prebuilt' class which generates a tarball of ${D} in deploy/prebuilts after do_install task. Symmetrically, It's also possible to create an 'install-prebuilt' class which bypasses do_fetch, do_unpack, ..., do_install with noexec flag and instead uncompresses a previously generated prebuilt tarball into ${D} and continue normally. But I would like something smarter, e.g. first trying to check if the SRC_URI is available, if not switching on using the prebuilt package if available (e.g. in a DIR_PREBUILT)...
>
> Before going further is there already an existing solution for that? do you have any recommendation on the easier/best way to achieve this?

I did initially try the approach of having a single recipe which can
automatically support both building from source and extracting a
prebuilts tar file, but that (for me anyway) turned out to be a dead
end. Building from source requires build dependencies and config
options but extracting a prebuilt tar file does not, so the two end up
sharing very little... so 90% of the recipe ends up being conditional
on which mode it's running in. The solution I ended up with (see link
above) was for the class which creates the prebuilt tar file to also
create a dedicated mini recipe to extract it.

From my experience however an equally hard part of the problem is the
distribution of prebuilts. It starts off easy (you share a tar file
via email or an ftp site and the receiver manually copies to their
downloads directory...) but that doesn't scale if you need to make
regular updates. My solution is discussed a little more in the thread
linked to above.


  parent reply	other threads:[~2019-08-23 18:11 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-05 16:06 Automatic prebuilt management Loic Poulain
2019-08-05 16:39 ` chris.laplante
2019-08-23  9:49   ` Loic Poulain
2019-08-23 18:11 ` Andre McCurdy [this message]
2019-08-30 16:27   ` Loic Poulain
2019-08-30 16:45     ` 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='CAJ86T=XwwjSZR6oNdXCr=bvbOKw5trKWJ=na4=_+83vXXJo6Bw@mail.gmail.com' \
    --to=armccurdy@gmail.com \
    --cc=loic.poulain@linaro.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.