Fix symlinks for gmergefs on stateful and keep other stateful items installed from build_image

Fix symlinks for gmergefs on stateful and keep other stateful items installed from build_image

[sosa, 2010-04-06 23:09:49]

Persists var.

[Chris Masone, 2010-04-06 23:40:23]

http://codereview.chromium.org/1561014/diff/10001/11001
File src/scripts/build_image (right):

http://codereview.chromium.org/1561014/diff/10001/11001#newcode251
src/scripts/build_image:251: sudo ln -s "$DEV_IMAGE_ROOT"
"$DEV_IMAGE_ROOT/usr/local"
why don't we want dev_image/usr/local to just be a directory?

http://codereview.chromium.org/1561014/diff/10001/11001#newcode260
src/scripts/build_image:260: sudo mount --bind "$DEV_IMAGE_ROOT"
"$ROOT_FS_DIR/usr/local"
and then symlink this to dev_image/usr/local?

http://codereview.chromium.org/1561014/diff/10001/11001#newcode342
src/scripts/build_image:342: sudo ln -s "/var" "$DEV_IMAGE_ROOT/var"
this symlinking stuff...can you pull it into a function to which you pass a
target base path?  Like, you call it once wth $DEV_IMAGE_ROOT and then again
down here with /usr/local?  it seems like the above symlinking bit and this bit
need to be kept in sync, and sequestering the logic in a function would be
ideal.

[sosa, 2010-04-06 23:51:43]

http://codereview.chromium.org/1561014/diff/10001/11001
File src/scripts/build_image (right):

http://codereview.chromium.org/1561014/diff/10001/11001#newcode251
src/scripts/build_image:251: sudo ln -s "$DEV_IMAGE_ROOT"
"$DEV_IMAGE_ROOT/usr/local"
On 2010/04/06 23:40:25, cmasone wrote:
> why don't we want dev_image/usr/local to just be a directory?
It's rather complicated, but remember at run-time we're mount dev_image onto
/usr/local of the rootfs.  At build time, we're installing developer-only
packages using emerge --root = dev_image.  I think if you do the symlinks /dir
approach something breaks in this process (i.e. i don't really understand how
that would work)

http://codereview.chromium.org/1561014/diff/10001/11001#newcode342
src/scripts/build_image:342: sudo ln -s "/var" "$DEV_IMAGE_ROOT/var"
Good idea, i'll see if i can function-ize

On 2010/04/06 23:40:25, cmasone wrote:
> this symlinking stuff...can you pull it into a function to which you pass a
> target base path?  Like, you call it once wth $DEV_IMAGE_ROOT and then again
> down here with /usr/local?  it seems like the above symlinking bit and this
bit
> need to be kept in sync, and sequestering the logic in a function would be
> ideal.

[sosa, 2010-04-07 18:08:03]

I believe I've addressed the concerns.  PTAL

[Chris Masone, 2010-04-07 18:32:39]

http://codereview.chromium.org/1561014/diff/19001/20001
File src/scripts/build_image (right):

http://codereview.chromium.org/1561014/diff/19001/20001#newcode157
src/scripts/build_image:157: sudo unlink "${DEV_IMAGE_ROOT}/usr"
If this is something other than a symlink, do we want to silently ignore it?

http://codereview.chromium.org/1561014/diff/19001/20001#newcode160
src/scripts/build_image:160: sudo mkdir -p "${1}"
Don't we want ensure this is there?  And, if it's already there, this is a
no-op, right?

http://codereview.chromium.org/1561014/diff/19001/20001#newcode168
src/scripts/build_image:168: sudo unlink "${DEV_IMAGE_ROOT}/var"
same Q as above

http://codereview.chromium.org/1561014/diff/19001/20001#newcode171
src/scripts/build_image:171: sudo mkdir -p "${2}"
ditttttto

[sosa, 2010-04-07 19:16:55]

http://codereview.chromium.org/1561014/diff/19001/20001
File src/scripts/build_image (right):

http://codereview.chromium.org/1561014/diff/19001/20001#newcode157
src/scripts/build_image:157: sudo unlink "${DEV_IMAGE_ROOT}/usr"
On 2010/04/07 18:32:39, cmasone wrote:
> If this is something other than a symlink, do we want to silently ignore it?

Done.

http://codereview.chromium.org/1561014/diff/19001/20001#newcode160
src/scripts/build_image:160: sudo mkdir -p "${1}"
On 2010/04/07 18:32:39, cmasone wrote:
> Don't we want ensure this is there?  And, if it's already there, this is a
> no-op, right?

This is for the second call to this function.  Where we basically symlinks to
the new locations based on root.  We don't want to modify the chroot with these
changes ... i.e. while it's no biggee, I don't want to create /usr/local in the
chroot just to create a symlink.  I'd rather create a fake symlink that just
works on the target since I set it up on the first run

http://codereview.chromium.org/1561014/diff/19001/20001#newcode168
src/scripts/build_image:168: sudo unlink "${DEV_IMAGE_ROOT}/var"
On 2010/04/07 18:32:39, cmasone wrote:
> same Q as above

Done.

http://codereview.chromium.org/1561014/diff/19001/20001#newcode171
src/scripts/build_image:171: sudo mkdir -p "${2}"
On 2010/04/07 18:32:39, cmasone wrote:
> ditttttto

ditto back

[Chris Masone, 2010-04-07 21:54:51]

http://codereview.chromium.org/1561014/diff/27001/28001
File src/scripts/build_image (right):

http://codereview.chromium.org/1561014/diff/27001/28001#newcode161
src/scripts/build_image:161: fi
Can't this be simplified?  if it exists and isn't a symlink, error and return. 
Then just do the unlink after.

http://codereview.chromium.org/1561014/diff/27001/28001#newcode163
src/scripts/build_image:163: if [ ${3} -eq ${FLAGS_TRUE} ] ; then
Hm.  I'm just wondering if there's a way that we can get rid of the last
argument...Perhaps you can do the mkdirs outside the function?  Since it's only
necessary in one of the two cases?

[sosa, 2010-04-07 22:08:21]

PTAL, also removed lazy unmounts that bill didn't like

http://codereview.chromium.org/1561014/diff/27001/28001
File src/scripts/build_image (right):

http://codereview.chromium.org/1561014/diff/27001/28001#newcode161
src/scripts/build_image:161: fi
No cause it might not exist (but that shouldn't be an error) if I try to unlink
something that doesn't exist I'll get an error.

On 2010/04/07 21:54:51, cmasone wrote:
> Can't this be simplified?  if it exists and isn't a symlink, error and return.

> Then just do the unlink after.

http://codereview.chromium.org/1561014/diff/27001/28001#newcode163
src/scripts/build_image:163: if [ ${3} -eq ${FLAGS_TRUE} ] ; then
Sure. done.

On 2010/04/07 21:54:51, cmasone wrote:
> Hm.  I'm just wondering if there's a way that we can get rid of the last
> argument...Perhaps you can do the mkdirs outside the function?  Since it's
only
> necessary in one of the two cases?

[Chris Masone, 2010-04-07 22:15:39]

lgtm