[arch-general] archroot - proper way to Start Over? (rm -r $CHROOT/$USER)?

[C Anthony Risinger]

On Wed, Mar 7, 2012 at 12:27 PM, C Anthony Risinger <anthony at xtfx.me> wrote:
>
> ... i thought you were asking a) "share a base read-only chroot", so
> you don't have to rebuild/clean it.  since the base is readonly, you
> must then --bind mount (shared/persistent) or create an empty
> repository (within the overlay only) at /repo (i believe there is some
> built-in support for this).  then you instruct makechrootpkg to (or
> manually) install the recently built package to that repository, and
> continue with next build.  when you want to start the next full
> rebuild (TQt3), you simply remove the unwanted packages from the
> chroot (eg, pacman -r {path-to-chroot}).

^^^^^ i meant to describe the overlay stuff too ... was rushing out
the door to an appt ...

the above should work with or without an overlay.  the benefit of the
overlay/union is you can easy change layers, and isolate each build.
for example, the unionfs FUSE module i linked simply diverts your
writeable layer to a different directory, allowing you to stuff like
this:

-----------------------------------------------
APPLICATION (makepkg)
--> VFS [mkdir, unlink, *syscall]
--> /rw-build-XYZ (build layer)
--> /ro-tqt3 (core layer)
--> /ro-base (base layer)
-----------------------------------------------

... so, you'd start with 3 empty dirs, then:

) setup a base chroot in /ro-base (including ccache + configs)
) mount unionfs with [RO] /ro-base and [RW] /ro-tqt3
) install core packages needed by TQt3
) ... all changes, and only the changes, will now be in /ro-tqt3
) remount: [RO] /ro-base, [RO] /ro-tqt3, [RW] /rw-build-NAME
) perform build (ensure .ccache dir is available inside chroot)
) install to /repo
) [repeat the last 3 steps for each package]

... may need adjustments; pacman doesn't like any of this.  i've never
done 3 layers like i briefed above -- you could put each pkg in a
separate layer if you *really* wanted -- but i frequently use 2, the
ro-base and rw-build-NAME. seriously, ccache makes stuff so fast that
it's probably slower to putz around vs. just using a fresh rw-build-*
each time you need to.

although, it might be kind of cool to extract all of your source
tarballs to separate dirs, say:

-----------------------------------------------
/path/.../layers/out/@trinity-20120307/{source}
[...]
/path/.../layers/in-out/@repo-20120307/repo
[...]
/path/.../layers/in/@base/{mkarchroot}
[...]
/path/.../layers/in/arts/PKGBUILD
/path/.../layers/in/dbus/PKGBUILD
/path/.../layers/in/caldav/PKGBUILD
/path/.../layers/in/tdelibs/PKGBUILD
-----------------------------------------------

... then mount it up so it looks something like this (one command, see
unionfs options):

-----------------------------------------------
APPLICATION (makepkg)
--> [RW] @trinity-20120307/
--> [RW] @repo-20120307/
--> [RO] @base/
--> [RO] arts/
--> [RO] dbus/
--> [RO] caldav/
--> [RO] tdelibs/
-----------------------------------------------

... hell, you could fancy and use individual git repos + commit when
you update a src ... throw in a few scripts and you might have a
pretty cool build system capable of building any available combination
of pkg X, Y, Z, *and* rolling back in time to build against older
versions with a simple `git checkout` ... yeah, i'm going to play with
this.

o_O

are you sufficiently confused yet?  because i can keep going if you
like :-) but i'm getting a bit lost myself.  the point of the exercise
is that unionfs and other layering solutions permit incredible build
re-use and flexibility.  the biggest challenge is making pacman to
deal with the craziness ... we need a proxy pacman db (FUSE) that will
lie to pacman when it tries to read it.

tldr; try a 2-layer setup and see how it works for you.

--

C Anthony