Proof of concept remote builder of clean Gentoo tree to provide on demand binary packages to desktop and
laptop comptuers. 

 - The configuration between builder and base system should not diverge even in minor details. Otherwise,
 fancy effects may happen, particularly with perl/python/ruby. Virtuals for perl may offer a few versions
 of perl package as a variants. When built, a specific version is registered in the binary package. Then,
 this becomes hard dependency likely causing slot conflicts - host wants to update to 5.30 (unmasked), but 
 some perl virtuals are for 5.28).
 
 - This will not work with presence of any significant unstable packet.
    * For instance, unstable firefox depends on unstable "nss-3.45". After update it is replaced in portage
    with "nss-3.46". Either full "nss-3.*" branch should be unmasked (which may bring its own problems or the
    manual intervention is required)
 - Even with stable tree, there are pereodically circular dependencies (always during the bootstrap phase)
 
 
Idea:
 - Create 'Bootstrap' image, i.e. Gentoo image with all configuration. Solved circular dependencies ready to build
    make bootstrap
    make check
    
 - Instantiate 'Builder', i.e. synced configs and portage tree (not needed, but kept for comptaibility)
    make builder
    make bash

 - Update builder to integrate latest configuration/portage changes (not needed, builder updates itself)
    make update
    make bash
    
 - Start building
    make build
    make logs

 - On major updates (perl/python/ruby especially), it could make sense to re-create builder from latest
 gentoo snapshot and restart (many packages will be re-used, so little performance penalty). 
   * Some binary packages may be built against old versions of library, etc. There is mechanism to trigger rebuilds,
   but it would not work in this case?

    
 It will build packages and put it on the attached volume. The script is designed to run forever. 
  * If crashed it will start idle sleep until the connected user solves the problem and kills the 
  sleep. It will restart building, then.
  * If it finishes, it will re-sync after given interval or just wait until the user triggers rebuild
  manually, again by killing sleep.

 If the script is restarted for some reason (crash/server reboot), emerge will first re-use already
 built binaries and, then, will continue compilling. 
  * At some point a snapshot could be made by converting 'container' into the huge 'image' with 
  'docker commit'.
  

Problems:
  - This requires large and fast storage. I guess overlayfs2 based stuff is helpful (as of Oct 2019,
  overlayfs2 causes performance problems for eix-sync and should not be used) .
  
  - It also requires a novel kernel on the docker machine. For instance, QT would not
  compile on the old kernel. The library now may incorporate information about the minimum
  kernel version which is required to run it, e.g.
      readelf -n /usr/lib64/libQt5Core.so|grep Linux 
        OS: Linux, ABI: 3.17.0
  However, such elf-header is (at the moment) also preventing it from linking. So, you not
  only unable to run a novel QT with old kenrel, but also compile it.


Status:
  - Builder is able to fully built my configuration. I can't use it due to divergence in perl versions (perl-5.30 unmasked)
  Technically, it should work once perl-5.30 get stable.

  - How system survives update of major subsystem (perl, python)? While it update automatically or shall we re-create builder?
  In the later case, will it handle required re-builds automatically? Or do we need also to delete some binaries (at least 
  paritally).