Openembedded Devel Discussions
 help / color / mirror / Atom feed
From: Koen Kooi <k.kooi@student.utwente.nl>
To: openembedded-devel@lists.openembedded.org
Subject: Re: The coreutils-native race...
Date: Mon, 26 Apr 2010 08:30:54 +0200	[thread overview]
Message-ID: <hr3buu$pps$1@dough.gmane.org> (raw)
In-Reply-To: <1272225464.3865.549.camel@trini-m4400>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 25-04-10 21:57, Tom Rini wrote:
> 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..

I have no problem with changing the libpam-base-files SRC_URI to

file://pam.d/

or

file://foo.pam \
file://bar.pam \
...
etc

But I would like to see it documented in the OE manual that file://dir/*
can't be used, and why.

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFL1TMeMkyGM64RGpERApkGAJ97rdsQSb+HvBKP2xKUdyAvqyfqPgCfUEBG
h/0qC3TUbMrfO0oOvZv9mmk=
=cb0z
-----END PGP SIGNATURE-----




  reply	other threads:[~2010-04-26  6:34 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-25 17:48 The coreutils-native race Tom Rini
2010-04-25 18:51 ` Phil Blundell
2010-04-25 19:28 ` Koen Kooi
2010-04-25 19:57   ` Tom Rini
2010-04-26  6:30     ` Koen Kooi [this message]
2010-04-26 14:59       ` Chris Larson
2010-04-25 20:42 ` Roman I Khimov
2010-04-25 21:12   ` Tom Rini
2010-04-25 21:16   ` Yuri Bushmelev

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='hr3buu$pps$1@dough.gmane.org' \
    --to=k.kooi@student.utwente.nl \
    --cc=openembedded-devel@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox