All of lore.kernel.org
 help / color / mirror / Atom feed
From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Martin Jansa <martin.jansa@gmail.com>
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [PATCH] sstate: add manifest info for shared file matches
Date: Fri, 19 Oct 2012 12:07:05 +0100	[thread overview]
Message-ID: <1350644825.2520.19.camel@ted> (raw)
In-Reply-To: <20121019105559.GJ3087@jama.jama.net>

On Fri, 2012-10-19 at 12:55 +0200, Martin Jansa wrote:
> On Thu, Oct 18, 2012 at 12:25:05PM -0700, Saul Wold wrote:
> > Present the manifest file that contains the matches for
> > files being installed to a location that already contains
> > that file. This will help to determine which is the correct
> > recipe to fix when this occurs.
> > 
> > [YOCTO #3191]
> 
> Can we do the same when removing files from sysroot?
> 
> To catch errors like this:
> http://git.openembedded.org/openembedded-core/commit/?id=6b12d4cd39bacb087654b59e25f5052a4e839b26
> 
> 12:40:15 < JaMa> it depends on order of tasks
> 12:41:27 < JaMa> gettext-native depends on gettext-minimal-native, so gettext-minimal-native installs own config.rpath to sysroot (when gettext-native "owns"
>                  it too)
> 12:41:55 < JaMa> then gettext-native is built and before populting sysroot it removes own files there (including config.rpath)
> 12:43:45 < JaMa> and because sstate assumes that every file in sysroot is provided by exactly one recipe, gettext-minimal-native looses his config.rpath
> 12:44:49 < JaMa> now there is at least warning when 2 recipes are installing the same file to sysroot, but that doesn't resolve this issues when some file is
>                  "moved" between recipes
> 12:47:30 < JaMa> because gettext-minimal-native is only recipe installing it
> 12:47:39 < JaMa> and gettext-native is only removing it
> 
> If we check manifests from other recipes before removing files we can show warning that
> gettext-native is trying to remove config.rpath now provided by gettext-minimal-native
> and keep config.rpath in sysroot.

The plan is to make it a hard error if something installs a file that
already exists. This issue will be resolved when that happens and I want
to get there sooner than later.

Running the check at sysroot clean time is therefore going to complicate
the code a lot and damage performance with no real end need...

> Now everybody doing incremental builds needs to call
> bitbake -c cleansstate gettext-minimal-native

-c clean should be sufficient. I wish people would use appropriately
sized hammers and this is why I never wanted cleansstate in the first
place :(.

Cheers,

Richard




  reply	other threads:[~2012-10-19 11:20 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-18 19:25 [PATCH] sstate: add manifest info for shared file matches Saul Wold
2012-10-19 10:55 ` Martin Jansa
2012-10-19 11:07   ` Richard Purdie [this message]
2012-10-19 11:29     ` Martin Jansa
2012-10-19 14:41 ` Chris Larson

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=1350644825.2520.19.camel@ted \
    --to=richard.purdie@linuxfoundation.org \
    --cc=martin.jansa@gmail.com \
    --cc=openembedded-core@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.