Tehát, akkor a tuti Gentoo üzemeltetés, ahogy én látom:
1. Saját portage tree snapshot kell. Ha rsync a frissítés technológiája (én most ezt használom), akkor saját (napi) rsync frissítés valami környezetbe (nálam egy chrootban lakik), amiről aztán lehet csinálni snapshotokat, és azokról megy minden gép és minden fordítás. Ennek hiányában nem tudsz pl. kettő gépet csomagszinten azonos állapotban tartani. Elvileg a git használatával nem is kellenének snapshotok, hiszen azzal előre-hátra lehet menni az időben, de nálam most ez van összelőve.
2. Az a felállás, hogy egy éles gépen, az éles környezetben fordítgatja az ember azokat csomagokat, amiket rögtön oda fel is rak, az alapvetően nem működőképes. Nem lehet reprodukálni az eredményt, ha elbökődik valami, akkor lehet elővenni a mentést, meg hasonlók. Emiatt külön fordítási környezet kell, vagy chrootban (én ezt használom, mert kényelmesebb), vagy virtuális gépben, ahol bináris formában előállnak a csomagok, amit aztán lehet a célkörnyezetekbe felrakni. Innentől adódik, hogy a frissítés úgy néz ki, hogy a napi frissítésű portage tree-ből csinál az ember egy snapshotot, a fordítási környezetből csinál egy másolatot, abban frissít a portage tree snapshotra, majd frissíti a szimpatikus csomagokat. Ha elbaszódik valami, akkor lehet javítani vagy újrapróbálkozni, a problémák döntő többsége még fordításkor kijön.
3. Optimális esetben van valami tesztkörnyezete az embernek, ha más nem, hát egy virtuális gép megfelelhet erre, de egy kevésbé kritikus gép is jó lehet. Először ide rakja fel az ember a frissített csomagokat (az ugye már a fordítási környezetben kiderült, hogy egyáltan lefordul minden), és nyilván valami alapszintű tesztelést azért gyorsan le lehet nyomni.
4. Frissítési taktika: nálam az vált be, hogy időnként (jellemzően valami alapvető package - pl. glibc/gcc - változása után, ~fél évente) nyomok nulláról egy full újrafordítást, közötte meg snapshot + frissítgetek, ahogy nekem szimpatikus. Mivel a frissítés után nem nulla energiát igényel a deployment, hiszen az adott komponenst használó dolgokat minimum ki is kell próbálni, így nyilván a rászánható időtől függ, hogy mikor mit frissítek. Jellemzően aminek tud security vonzata lenni, vagy ismerten van is neki, az frissül, egyébként meg nem nagyon. Nálam nincs GLSA-alapú automatizálás, már csak azért sem, mert minden frissítéshez snapshot tartozik. Van viszont script, ami napi jelleggel kiszedegeti az általam megjelölt fontosabb csomagok állapotát a használt architektúrákban, és az utolsó frissítésemhez képest tud mondani diffet.
Amivel szopás van:
gcc-csere: újabb gcc-vel fordított C++ programhoz kell az újabb gcc C++ libje, ergó nem tudsz binárisban felrakni új dolgot, ha nincs elég friss gcc a gépeden, itt legalább annyira nem szar a helyzet, mert lehet fent több gcc verzió, és lehet a régi a default
glibc-csere: ez a nettó, tömény szopás; két glibc verzió nem tud fönt lenni, az újabb glibc-hez linkelt programok by default nem mennek a régebbivel, emiatt a downgrade is elég necces tud lenni
Ha eltérő feature set-ek kellenek (pl. egymásnak ellentmondó USE-flagek, egymást kizáró csomagok, más CFLAGS, stb), akkor annyi példányban kell fordítási környezetet fenntartani, ez azért egy ponton túl már sok macera tud lenni; én most egyetlen halmaznyi csomagot, USE-flageket, és egy CFLAGS beállítást használok csak. Az is macera, hogy az eltérő architektúrákra nem pont ugyanazok a csomagok és nem egyforma státusszal állnak rendelkezésre.