[linux-yocto] KMETA branch/directory redux (yocto #5090)

[Peter A. Bigot]

On 08/29/2014 03:02 PM, Bruce Ashfield wrote:
> On 14-08-29 03:31 PM, Peter A. Bigot wrote:
>>
>> The point is that issuing a mv like:
>>
>>         mv $checkpoint_dir .$checkpoint_dir
>>
>> without ensuring that the value of the variable doesn't contain path
>> components is fragile.  I'm not really clear on the goals of the
>
> It can use some extra sanity checking, but since it is searching out
> directories already on the disk to use, we do know that the contents
> of the variable are safe for on disk representation.

That's not the issue.  The issue is that if $checkpoint_dir is a/b/c/d, 
the path .a/b/c probably doesn't exist into which d can be moved.  You'd 
have to do something like:

    mkdir -p .$(dirname $checkpoint_dir)
    mv $checkpoint_dir .$checkpoint_dir

and even that wouldn't do the right thing in all cases.

>
>> construct, especially as the dot-qualified name didn't appear to be
>> referenced again when I solved this locally.  If that's true, why not
>> just delete it?  If there's some reason it needs to continue to exist in
>> the filesystem, why not move it to ".checkpoint_dir" (as a bare name,
>> not as the value of a variable)?
>
> The dot directory isn't used by the checkpoint scripts after that point,
> but it is used by most of the tools/scripts that follow. So it does
> need to stay around.
>
> There can technically be multiple meta data directories in a single
> tree, hence why the name of the directory is reused in the .<name> 
> format.
>
> The point of the checkpoint restored directory is to make it available
> to each and every branch in the tree during processing, since the
> update, patching and configuration steps use that meta data to
> manipulate the tree while changing branches, etc.
>
> To make it globally available .. without needing to have it be part of
> those branches (i.e. committed and merged to the branches), making it
> untracked content solves the problem. And to make it so it doesn't show
> up in 'git status', and so that we can continue to check out and work
> with the meta branch itself, making the directory a ".<meta>" name
> solves the problem.

OK.  At this stage I just want "bitbake linux-yocto" to work with 
branches that look like path hierarchies in workspaces that don't 
attempt to share build areas among multiple meta configurations. Any 
other capabilities hidden in yocto-kernel-tools are things I haven't 
encountered yet.

I'll wait until everything's available to comment more.

Peter