[OE-core] migrating simple tarballs over to OE recipes?

[Robert P. J. Day]

On Wed, 23 Nov 2016, Martin Jansa wrote:

> On Wed, Nov 23, 2016 at 01:00:12PM +0100, Ulf Magnusson wrote:
> > On Wed, Nov 23, 2016 at 12:34 PM, Robert P. J. Day
> > <rpjday at crashcourse.ca> wrote:
> > > On Wed, 23 Nov 2016, Burton, Ross wrote:
> > >
> > >>
> > >> On 23 November 2016 at 10:42, Robert P. J. Day <rpjday at crashcourse.ca> wrote:
> > >>         colleague has a pile of tarballs that were used to
> > >>       customize an x86 centos system, wants to move all that to
> > >>       OE with as little fuss as possible, i guess the simplest
> > >>       way is to just create recipes that have the same tarball
> > >>       in the files/ directory, and write a trivial do_install()
> > >>       task that untars it into the root fs, yes?
> > >>
> > >>
> > >> Pretty much, yeah.
> > >>
> > >> If you've a large pile and they're all effectively the same
> > >> then a little class can automate it even more.
> > >
> > >   already going down that road, just wanted to make sure i
> > > hadn't overlooked something obvious.
> > >
> > > rday
> >
> > bin_package.bbclass might be useful as well, especially if the
> > files are already arranged like in the rootfs inside the tarballs.
>
> If these files are overwriting files owned by some other packages,
> then you will loose that customization when the package is upgraded
> by package manager (unless those files are listed in CONFFILES). You
> need to use RREPLACES at least.
>
> > do_install() task that untars it into the root fs, yes?
>
> ? do_install installs them to $D not root fs which doesn't even exist yet.
>
> You might also need to skip strip if there are also some binaries
> which are already stripped, skip ldflash qa check if they don't have
> matching hash type etc

  ok, let me clarify/simplify a few things to zero in on the optimal
solution.

  first, there are several dozen tarballs, all containing content
relative to the very top of the root directory, and i've been assured
they're proprietary application-specific and hence won't clash with
any "regular" recipes/RPMs. rather than trying to verify that, i'm
just going to accept that. so something along the lines of
bin_package.bbclass would seem to be acceptable.

  (SIDE NOTE: i was asked if recipes could be written so that the
accompanying "files/" directory contained, not a single tarball, but
the actual, *exploded* content in directory structure to be copied
as-is into the target rootfs. i've never seen that, is that ever done?
i'm not sure how i'd even assign to SRC_URI to handle that. so i'll
insist on tarballs.)

  second, given content all in a single tarball, i'm assuming i'd use
simply:

    SRC_URI = "file://rday.tar.gz"

  finally, looking at bin_package.bbclass, i'm puzzled by this:

  do_configure[noexec] = "1"
  do_compile[noexec] = "1"

  # Install the files to ${D}
  bin_package_do_install () {
    # Do it carefully
    [ -d "${S}" ] || exit 1
    cd ${S} || exit 1
    tar --no-same-owner --exclude='./patches' --exclude='./.pc' -cpf - . \
        | tar --no-same-owner -xpf - -C ${D}
  }

  FILES_${PN} = "/"

  EXPORT_FUNCTIONS do_install

what is the relationship between bin_package_do_install() and the
EXPORTed do_install()? seems like an overriding/inheritance thing,
yes?

  anyway, i think i can see the way to go.

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================