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

[Bruce Ashfield]

On 14-08-29 04:32 PM, Peter A. Bigot wrote:
> 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:

There aren't any checkpoint directories of that name, at
least not valid ones.

>
>     mkdir -p .$(dirname $checkpoint_dir)
>     mv $checkpoint_dir .$checkpoint_dir
>
> and even that wouldn't do the right thing in all cases.

I'm restricting what is valid, so I don't have to worry about the
case of deeply nested directories. I only get the top level directory
name, and rename it. The subdirs don't matter.


>
>>
>>> 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.

And it already will. I'll confirm with a test, but the changes I have
don't care what you name the branch anymore. They just look at the
disk and see what the top level directory is called, and use it as is.

Bruce

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