[oe] The coreutils-native race...

Tom Rini tom_rini at mentor.com
Sun Apr 25 19:57:44 UTC 2010


On Sun, 2010-04-25 at 21:28 +0200, Koen Kooi wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 25-04-10 19:48, Tom Rini wrote:
> > Hey all.  I thought I would try and explain what Chris has been up to
> > with at least some of the base.bbclass changes (the ones related to
> > md5sum and cp).
> > 
> > Right now, with a big enough BB_NUM_THREADS we can get into a race where
> > coreutils-native is installing programs and elsewhere we are in a
> > do_fetch and either trying to use 'cp' or 'md5sum', and blam, we try and
> > invoke the program while it's being installed (and see things like
> > sh: /path/to/staging/i686-linux/usr/bin/cp: Textfile is busy).
> > 
> > There's a few ways out of this:
> > 1) Don't rely on 'cp' and 'md5sum' anymore but use python for it.
> > 2) Make an oe_cp and oe_md5sum to go with oe_sha256sum
> > 3) IIRC, the big part of coreutils-native was a fully functional,
> > always, 'install'.  We could just copy the install we build or provide
> > an install wrapper (oe_install) or so
> > 4) ???
> 
> Even thought I loathe python, option 1 sounds like a nice way to go
> since it doesn't involve butchering recipes.

I think we're OK, except in the case of when we can't rely on a built-in
md5sum (and then the race comes back) and just need to figure out if the
libpam-base-files recipe does things (a) optimally and (b) if that's a
common thing.

Currently, with a quick glance at the recipe, I don't see any
distro-specific overrides, so I'd be inclined to call it lazy recipe
writing, until someone points out history of why that's a good thing..

-- 
Tom Rini <tom_rini at mentor.com>
Mentor Graphics Corporation




More information about the Openembedded-devel mailing list