[oe] The coreutils-native race...

[Roman I Khimov]

В сообщении от Воскресенье 25 апреля 2010 21:48:59 автор Tom Rini написал:
> 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.

I guess it couldn't really be done, since those could be invoked from any 
shell script, right? Although it only is a concern for things before 
do_configure, so there shouldn't be many scripts there.

> 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

We've had install-native, but that was some broken dusty script that act like 
a detonator - you build some package having it in DEPENDS (not many had, but I 
was lucky enough) and boom! random packages brake randomly in do_install 
because of disfunctional install.

I've proposed back then to just drop it. But there've been a concern that for 
reliable builds it's better to be sure that we have known proper install and 
that is provided by coreutils along with many other things, which are also 
good to have in some known good state for an OS-independent build system.

This is the way we've got to the point of having coreutils-native in all of 
our builds.

Although, as I'm personally building my things on sane GNU hosts with sane 
coreutils with known nice install, I've always had coreutils-native in 
ASSUME_PROVIDED. Thus, not seeing any failures with usual 4 bb threads.

I guess, if we can solve it with python, it's the best option. If not, then we 
can try to remove coreutils-native from base dependencies and see how much 
breakage it introduces. Shouldn't be a problem for most of Linux distros, but 
for other platforms it may be.

-- 
 http://roman.khimov.ru
mailto: roman at khimov.ru
gpg --keyserver hkp://subkeys.pgp.net --recv-keys 0xE5E055C3
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.openembedded.org/pipermail/openembedded-devel/attachments/20100426/e747c954/attachment-0002.sig>