Miroslav Prýmek wrote:
Ja to tak delam na desitkach stroju takze vim co znamena "straslive
zpomali". A nepripada mi to tak strasne aby me to donutilo ...
Obcas nekde mam uzky pasmo, takze to zpomaleni je az k
nepouzitelnosti... (syncovani v noci mi nevadi, ale zpomaleni
interaktivity jo)
Tak to nedelej interaktivne ;-)
Staci k portupgrade nedat option -i
Cil:
1. strom portu s vlastnima upravama a par vlastnima portama
2. preklad probiha jenom na A (viz niz)
3. klienti (viz niz) stahuji jenom to, co nutne potrebuji
4. na klientech se pracuje s portupgrade uplne stejne jakoby meli
kompletni strom, az na to, ze se
tam nepreklada
Ano, to je "normalni" pozadavek.
Reseni:
A) "build server"
1. ma k dispozici kompletni strom portu a z nej builduje vsechny
potrebny balicky
2. jednou denne aktualizuje strom a aplikuje nejaky zmeny (jednak chci
treba vlastni zmeny
nekterych baliku, jednak mam uplne vlastni porty) + vytvori INDEX
Az sem spravne.
3. po aktualizaci z uplnyho stromu vytvori "polostrom", kterej obsahuje
jenom Makefily a INDEX
B) klienti
1. $PORTSDIR/packages/All maji namountovany z A pomoci NFS
2. "polostrom" refreshuji z A pomoci rsync
To jako, ze vytvareji lokalni kopii ? Jak jsme psal - podle me zbytecne.
Misto batchoveho rsyncu delej batchovy portupgrade z celeho stromu.
1. "polostrom" projde siti zarucene jen jednou
V noci nezajimave. Navic, pri portupgrade sice neco poleze dvakrat - ale
ne vsechno. Otazka je, jestli je vic "vsechno jednou" nebo "jen neco
dvakrat"
3. neni problem mit ruzny verze balicku (lisici se optionama), protoze
"polostrom" je stejnej
Mam centralni build a aktualizuji se z nich desitky stroju (dokonce
nektere nikolvi pod moji primou spravou) - neco u domacich uzivatelu,
neco v akademicke sfere, neco ve sfere komercni. Mene homogenni
prostredi si lze uz jen tezko predstavit. Presto se mi zatim dari
dosahnout "nejmensiho spolecneho jmenovatele" a neexistuje port, ktery
bych potreboval prelozeny ve dvou verzich s ruznymi optiony.
Mozna, ze ty's takovy nasel ...
Miroslav Lachman wrote:
Pokud se nejedna o distribuci tech baliku a omezeneho ports tree z
nejakeho embedded zarizeni s malym flash ulozistem, tak bych se na
takovehle uspory vykaslal.
U aktualizaci embedded zarizeni narazim spis na to, ze totalne rozezrane
RUBY (a neprilis efektivne napsany portupgrade) se na techto zarizenich
nevejde do pameti, a jelikoz jsou bezdiskove tak to nemuze zachranit ani
swap. Tudiz na tech portupgrade pouzivat nelze ...
Dan
--
FreeBSD mailing list ([email protected])
http://www.freebsd.cz/listserv/listinfo/users-l
