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
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
|
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).
|
