summaryrefslogtreecommitdiffstats
path: root/README
blob: 3bad064786cad3076a8a8f8413009ac1b64ed5d9 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
Proof of concept remote builder of clean Gentoo tree to provide on demand binary packages to desktop and
laptop comptuers. 

 - 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
    make builder
    make bash

 - Update builder to integrate latest configuration/portage changes
    make update
    make bash
    
 - Start building
    make build
    make logs

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