[OE-core] Automatically creating tar files for bin_package.bbclass

[Nicolas Dechesne]

hi Andre!

On Wed, Jul 6, 2016 at 10:21 AM Andre McCurdy <armccurdy at gmail.com> wrote:
>
> On Tue, Jul 5, 2016 at 3:27 PM, Richard Purdie
> <richard.purdie at linuxfoundation.org> wrote:
> > On Tue, 2016-07-05 at 08:12 -0700, Khem Raj wrote:
> >> On Tue, Jul 5, 2016 at 1:21 AM, Andre McCurdy <armccurdy at gmail.com>
> >> wrote:
> >> > On Mon, Jul 4, 2016 at 8:58 AM, Burton, Ross <ross.burton at intel.com
> >> > > wrote:
> >> > >
> >> > > On 4 July 2016 at 16:00, Andre McCurdy <armccurdy at gmail.com>
> >> > > wrote:
> >> > > >
> >> > > > Say I have a proprietary library which only I can build from
> >> > > > source
> >> > > > and I have a conventional recipe which builds it within OE. I
> >> > > > would
> >> > > > now like to create a tar file of the library and headers etc,
> >> > > > plus a
> >> > > > companion recipe based on bin_package.bbclass to allow others
> >> > > > to make
> >> > > > use of the library in their OE builds. ie the situation
> >> > > > described
> >> > > > here:
> >> > > >
> >> > > > http://www.yoctoproject.org/docs/2.1/mega-manual/mega-manual.ht
> >> > > > ml#packaging-externally-produced-binaries
> >> > > >
> >> > > > Is there a recommended way to create the tar file to support
> >> > > > that?
> >> > > > e.g. a class which automatically creates a deployable tar file
> >> > > > of a
> >> > > > recipe's ${D} directory?
> >> > >
> >> > > You *may* be able to use package_tar in the recipe in some way to
> >> > > achieve
> >> > > this.
> >> >
> >> > It only seems to support creating tar files after packages have
> >> > been
> >> > split ( ie individual tar files for each subdirectory under
> >> > ${WORKDIR}/packages-split ). I don't think it's going to be
> >> > directly
> >> > useful for creating a tar file of ${D}.
> >>
> >> package_tar is just another packaging format here so you will get
> >> individual package separately
> >> you might want to add another class to package everything into 1
> >> thats
> >> a separate issue, you have
> >> to either add this via a bbclass or additional function
> >
> > Personally, I think that involving package_tar is likely going to
> > overcomplicate this, as is packaging up the already separated out
> > packages.
> >
> > Better to provide the output as do_install would leave it in ${D}, and
> > then let packaging happen as the user has configured. Only tricky part
> > would be the lack of source for the debugging symbols but if you can't
> > release the source you'd want to "fix" that anyway.
>
> I think the common case is that you wouldn't want to include source or
> debug symbols, so using ${D} directly is still not perfect.
>
> Here's the generate-prebuilt-tarfile.bbclass I'm currently using. It's
> certainly not suitable for merging yet.
>
> ----
>
> DEPLOY_DIR_PREBUILTS ?= "${DEPLOY_DIR}/prebuilts"
>
> do_genprebuilt[depends] += "pbzip2-native:do_populate_sysroot"
> do_genprebuilt[dirs] = "${DEPLOY_DIR_PREBUILTS}/${PACKAGE_ARCH} ${WORKDIR}"
>
> do_genprebuilt() {
>
>     if [ "${CLASSOVERRIDE}" != "class-target" ]; then
>         exit 0
>     fi
>
>     TARFILE_BASENAME="$(echo ${PN}-prebuilt-${PV} | sed 's/AUTOINC+//')"
>
>     tar --transform "s|^image|$TARFILE_BASENAME|" --owner 0 --group 0
> -cvf - $(find image ! -type d | LC_ALL=C sort) | pbzip2 >
> ${DEPLOY_DIR_PREBUILTS}/${PACKAGE_ARCH}/$TARFILE_BASENAME.tar.bz2
> }
>
> addtask do_genprebuilt after do_install before do_populate_sysroot
>

has anything more been done on that topic? I happen to now need
something similar. E.g. packaging for proprietary content, and google
led me to this discussion. What's the recommended approach nowadays to
deal with recipes for proprietary content? The use case is similar,
when building internally, we want to build all sources, but when we
distribute, we want to distribute all open source content +
proprietary as blob, but with minimal (if not none) changes in the
meta data.


> ----
>
> > This way you don't need to worry if your tarball matches the users
> > package configuration options (which backend, which packaging options
> > etc.).
> >
> > Cheers,
> >
> > Richard
> >
> >
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core