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

[C Anthony Risinger]

On Fri, Mar 2, 2012 at 6:23 PM, David C. Rankin
<drankinatty at suddenlinkmail.com> wrote:
> On 03/02/2012 04:48 PM, C Anthony Risinger wrote:
>> IIRC makechrootpkg used to create an overlay/union before starting,
>> which would keep your original root intact.  if you put your builds on
>> a btrfs filesystem i believe makechrootpkg will snapshot the fs before
>> starting (i know im mixing mkarchroot and makechrootpkg a bit here
>> ...)
>>
>> imo, the most effective way is to use an overlay.  this FUSE based one
>> work just fine:
>>
>> http://podgorny.cz/unionfs-fuse/releases/
>>
>> ... as do many other methods (DM, btrfs, overlayfs, unionfs, etc etc),
>> though i persoanlly like the FUSE impl because it can cope with stuff
>> better without less risk of crashing.  you can then use --bind mounts
>> or multiple overlays to do interesting things too.
>>
>> make sure you've enabled `ccache` in your /etc/makepkg.conf, and
>> adjusted your `-jN` makeflag to an appropriate number.  i keep a 10GiB
>> cache around; i can blow away the webkit tree and start completely
>> fresh, apply my in-progress patchsets, and have a working package in
>> ~2 minutes (normally a 3+hr build).
>
> Thanks C Anthony,
>
>  It's the alphabet soup on top of the union filesystem and separate rw layer
> concepts that has my eyes rolling back in my head at the moment :)
>
> (re-reading the paragraphs for a 2nd time hoping it will all sink in)
>
>  OK, so what your are saying is that after I make friends with the snapshot
> concept (whether DM, btrfs, overlayfs, etc...) I can basically keep snapshots of
> different build 'points' in cache and switch back and forth relatively easily
> once I learn how -- right? So if I have one set of Trinity packages based on Qt3
> and another set based on TQt3, I can pickup building at the last good point of
> progress in either set by configuring the snapshot I need to create that
> environment? Like if I have built the dependencies through the snapshots below:
>
>     Trinity/Qt3                    Trinity/TQt3
>       Arts                           Arts
>       Dbus                           Dbus
>       caldav                         caldav
>       ...                            ...
>       tdelibs  (cache snapshot A)    tdelibs
>                                      tdebase  (cache snapshot B)
>
>
>  I could then configure the chroot to switch back to 'cache snapshot A' and
> continue building on Trinity/Qt3 at that point after I had saved snapshot B and
> reverted to the A cache?

i think i understand what your asking, and i'd say yes, you could ...
but it's not clear to me the actual problem/issue you are trying to
solve:

a) avoid recreating the base chroot (minimal)
b) reduce build times
c) independent overlay for each package?
c) [...] ?

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

... note, the above should work without a shared base as well, as
removing the packages would clean the base (remove header files/etc).
combined with `make distclean` and such should give a pristine working
environment.

also, ccache is unaffected by any of this, as it will do the right
thing in pretty much all situations; i fully recommend abusing the
hell out of that and saving *hours and hours* of rebuild times.

>  Would you happen to have a favorite link to a page that might help me get a
> bit smarter on this? :)

unfortunately not :-(  but if you have more issues/questions and the
like i'm happy to offer guidance (even if delay ;-)

-- 

C Anthony