All of lore.kernel.org
 help / color / mirror / Atom feed
From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Loic Poulain <loic.poulain@linaro.org>,
	Andre McCurdy <armccurdy@gmail.com>
Cc: OE Core mailing list <openembedded-core@lists.openembedded.org>
Subject: Re: Automatic prebuilt management
Date: Fri, 30 Aug 2019 17:45:54 +0100	[thread overview]
Message-ID: <c4e3f69a53cbc0a6e93970e3b4699447041e2aff.camel@linuxfoundation.org> (raw)
In-Reply-To: <CAMZdPi_bvV1Lcg_V3U1HpA_tH1AzWtpa0YMRg4MsNEgsOzApiQ@mail.gmail.com>

On Fri, 2019-08-30 at 18:27 +0200, Loic Poulain wrote:
> HI Andre,
> 
> On Fri, 23 Aug 2019 at 20:11, Andre McCurdy <armccurdy@gmail.com>
> wrote:
> > 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
> 
> Thanks, I missed that one.
> 
> > 
> > > 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.
> 
> Very good point. maybe having binaries also in a repo could help a
> bit (e.g. using git LFS).
>  
> > My solution is discussed a little more in the thread
> > linked to above.
> 
> Your solution is interesting and I'll probably jump on the thread
> with more questions.
> Having an upstream solution part of oe-core would be nice though.

We'd be happy to have one, it will take someone to propose something
suitably general purpose that others can use along with tests.

Cheers,

Richard



      reply	other threads:[~2019-08-30 16:45 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
2019-08-30 16:27   ` Loic Poulain
2019-08-30 16:45     ` Richard Purdie [this message]

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=c4e3f69a53cbc0a6e93970e3b4699447041e2aff.camel@linuxfoundation.org \
    --to=richard.purdie@linuxfoundation.org \
    --cc=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.