Intrebarea mea era ca pentru o distributie care se bate in piept cu orientarea pe securitate, diferentele fate de upstream ar face bine sa fie foarte justificate si urmaribile. Altfel este un spin cu "ce-i place lui Stefan/Marian/Vasile" care poate fi un argument de marketing/branding/whatever, dar nu de security.
2015-09-01 14:38 GMT+03:00 Stefan Cristian Brindusa < [email protected]>: > @ Peter R. > > Da, dar combo-ul pe care ti l-am zis are cam 40% legatura cu Gentoo pur, > restul sunt binare preconfigurate si automatizarea crearii lor, cat si a > ISOurilor. > Noi folosim Gentoo upstream in mod direct, si pushuim cand este necesar > prin bug reports direct la ei, avand in vedere ca si de la ei ne luam > multe. > In principiu, colaboram activ cu consiliul lor, parte din ei ne-am intalnit > la FOSDEM la cateva beri bune :) > > Parerea generala chiar si unor gentoo-isti este ca e necesar un distro > servers oriented care sa fie direct compatibil cu Gentoo, fara package > conflicts. > Si asta ne confera stabilitate. > > Also, tools-urile ce vi le-am enumerat mai sus fac urmatoarele lucruri in > urmatorii pasi (cronologic): vasile face "deploy" la gentoo stage3 care are > *entropy* binary package manager instalat. > Dupa deploy, la "vasile"poti sa-i dai o lista de programe ce s-o compileze, > si datorita prelucrarii noastre din overlay-urile noastre ( a fost necesar > sa splittuim pachete, in mod evident ) am stabilit o cale sigura de > compilare a unei liste de vreo minim 1300 de pachete ( care la o unitate de > 24 core iti face intr-o singura zi tot ). > Dupa compilare, folosim programul *eit* ca sa pushuim toate pachetele in > repositoriul / repositoriile noastre in mod automatizat, cu deps handling > si database cu tot. Practic tot ce trebuie sa faci e sa iei lista din > output-ul lui vasile, si sa dai *eit add $lista && eit push*. Automat va > arunca toate packages ( cu tot cu deps ) in repositoriu. Push-ul in repos a > 1300 pachete ( ~3.4 gb momentan) dureaza atat cat ai transfera de pe o > partitie pe alta (deoarece FTPul este intern, eit foloseste protocol FTP ca > sa pushuiasca pachete, si nici nu-i nevoie sa-l deschidem la extern, avem > alte metode de acces). > Again, toata schema de mai sus la o unitate de 24 core-uri ar dura undeva > la cateva ore. Deci putem extrapola ca 24 h putem avea 5000 pachete > compilate si pushuite intr-un singur repo (exista optunea sa le pushuiesti > si in mai multe, nu voi intra in detaili) > > Ulterior, dupa tot push-ul asta de pachete, avem tool-ul numit *molecule* > care > creaza in 9 pasi (in functie de niste shell-uri si vreo 3-4 .py-uri) > imagini ISO pe banda rulanta la rularea unei singure comenzi (evident, dupa > ce satisfaci o lista de pre-req): *molecule fisier.spec*, daca vrem sa > facem o lista ca sa creeze ISOuri pe banda rulanta, in mod evident, ii dam > cu for'u. > Spec-urile astea, gen > > https://github.com/BlackNoxis/rogentos-brand/blob/experimental/molecules/kogaion-amd64-mate.spec > care include while runtime fisierul > > https://github.com/BlackNoxis/rogentos-brand/blob/experimental/molecules/mate.common > ( unde cred ca e destul de evident care-i tot smenul ). > Din nou, la o masina de 24 core-uri, faci imagini ISO pe banda rulanta. > Momentan fac de ordinul a 10-15 ISOuri pe zi cu 8 core-uri ( 4 + 4 ) . > Imaginile rezultante sunt facute prin stabilizarea pasilor din shell-urile > ce sunt incluse in rularea interpretarii .spec-ului de catre molecule. > > Cat despre *quickpkg*, avem un model extravagand de misto. > Pentru cei ce nu au citit inca: *quickpkg iti creaza pachet binar cu toate > configuratiile personalizate de pe un program gata instalat (evident, > instalat cu emerge de la Gentoo)* > Mergand mai departe, daca folosesti quickpkg si-l transformi in pachet de > *entropy* cu o comanda amarata, si pachetul il vei transfera pe alt > Kogaion/Argent, vei putea instala pachetul *personalizat* cu equo install > si iti va lua cu tot cu deps necesare. > > *TL/DR*: Avem aproape totul automatizat. Aproape chiar tot. Wanna quick > patch and quick package and throw it into a centralized repo? No probs, il > bagi in ebuild, compilezi pachetul, il introduci in repo, te tine maxim 1-2 > minute. > > 2015-09-01 13:59 GMT+03:00 Petru Rațiu <[email protected]>: > > > 2015-09-01 12:54 GMT+03:00 Stefan Cristian Brindusa < > > [email protected]>: > > > > > Hello Dumitru, > > > > > > In patru cuvinte: vasile ( github.com/Rogentos ), *quickpkg* ( > > > https://wiki.gentoo.org/wiki/Binary_package_guide#Using_quickpkg + > > entropy > > > package manager ) ; *eit* (entropy-server) si *molecule* ( tot de > > pe'acolo > > > din suita de tools-uri de la Fabio Erculiani la care am contribuit 6-7 > > ani > > > ) > > > Acestea sunt motivele tehnice ^ de ce distributii pe Gentoo. > > > > > > > > Asta raspunde mai mult la "cum" si mai putin la "de ce". De ecemplu, vad > > prin overlay-urile alea o gramada de pachete cu diverse patchuri, nu e > > foarte evident de ce n-au fost bune cele de la upstream si de ce ati > decis > > voi sa folositi altele. > > > > PS: Pentru usurinta discutiei putem presupune ca ne-am mai dat cu gentoo > si > > cu overlay-uri si ca am mai compilat pachete si kerneluri si stim deja > cam > > cat magic e si nu e involved. > > > > -- > > P. > > _______________________________________________ > > RLUG mailing list > > [email protected] > > http://lists.lug.ro/mailman/listinfo/rlug > > > > > > -- > Main OS Architect at Project RoGentos (Romanian Gentoo Operating Systems) > Group. Based on Sabayon and Gentoo Linux, Kogaion GNU/Linux and Argent > GNU/Linux tend to offer support mainly for all Romanian Linux users and > entrepreneurs which seek to learn an open and free system based on true > values :) > http://rogentos.ro > www.facebook.com/RogentosLinux > https://plus.google.com/106559511636021124919/ Google+ > _______________________________________________ > RLUG mailing list > [email protected] > http://lists.lug.ro/mailman/listinfo/rlug > _______________________________________________ RLUG mailing list [email protected] http://lists.lug.ro/mailman/listinfo/rlug
