skrypty builderó

[Michal Moskal]

On Sat, Jun 07, 2003 at 11:00:33PM +0200, Andrzej Krzysztofowicz wrote:
> > > > Pozatym builder ma teraz opcję, że instaluje zbudowane pakiety. Tylko,
> > > > że to działa w 1/2 przypadków ze względu na zależności.
> > > 
> > > Nie jestem pewien, czy powinien. A jak to co sie wlasnie zbudowalo jest na
> > > tyle skopane, ze rozpieprzy system ?
> > > Wg koncepcji kloczka "zaakceptowaniem" pakietu dla instalacji na builderach
> > > mialo byc jago przejscie test -> ready.
> > 
> > Czekanie na przejście test -> ready jest IMHO nierealne, np. libtool ma
> > req-eq na gcc. I co przebudowujemy gcc i przerzucamy od razu do ready?
> > Przecież nie ma tam jeszcze libtoola. A w ready/ miały być pakiety spójne
> > pod względem zależności afaik.
> 
> Nie, ready mialo byc przechowalnia w ktorej pakiety czekaja *tylko* na
> spelnienie zaleznosci i podpisanie.
> Po tym mialy byc (mniej lub bardziej automatyczne) przesuwane do glownego
> drzewka + updates.

Ok, to czym się różni test/ od ready/?

> > > > Pytam dlatego, że doinstalowywanie i wywalanie BR może być rozwiązane
> > > > automatycznie (właśnie produkuje skrypty do tego). Jeśli zrobić tak jak
> > > > mówiłem (nie wywalać po budowaniu wszystkiego, ale tylko co co jest
> > > > zbędne dla następnego), to wydaje mi się, że można to zastosować na
> > > > builderach produkcyjnych. 
> > > 
> > > Tu tez mam watpliwosci.
> > > Nie do konca wierze, ze po
> > > 
> > > rpm -e pakiet;rpm -i pakiet
> > > 
> > > dostane *dokaldnie* taki sam stan systemu, jak przed wykonaniem tego.
> > > I nie chodzi mi tu a %files, a o pliki konfiguracyjne, skrypty %pre/%post
> > > i trigery. To czesto jest skopane.
> > 
> > AFAIK Pliki konfiguracyjne mają na builderach minimalne znaczenie, może
> > poza /etc/resolv.conf etc. W pakietach powinny być takie pliki konf,
> > żeby builder mógł na nich działać. Jakaś działająca domyślna konfiguracja.
> 
> Chodzi mi o te pliki %config, ktore sa modyfikowane przez skrypty
> (rejestracja xml, scrollkeepera, uzytkownikow, grup itd.)

Jeśli coś się będzie tu psuć, to znaczy, że mamy błąd, który trzeba
poprawić. Zresztą w tym układzie powinna być łatwa możliwość zrobienia
buildera od nowa (poldek -i rpm-build + cośtam może jeszcze i tyle).

> > > > No i jeśli budowanie będzie tylko kwestią puszczania zleceń (bez ssh
> > > > builder poldek -i ...), to powinno to pujść *znacznie* szybciej.
> > > 
> > > A roznice w szybkosci budowania pomiedzy architekturami ?
> > > A gdy zlecenie nie dojdzie na jakis builder na czas z powodu problemow z
> > > poczta ?
> > 
> > Ciężko wymusić, by zlecenia dochodziły w kolejności wysyłania,
> > szczególnie, jeśli wysyłających jest wielu. Ale IMHO kluczowa kwestia to
> > *taka sama* kolejność na wszystkich builderach. To na pewno rozjedzie
> > się przy zleceniach o wyższym priorytecie, ale to musimy przeboleć.
> 
> Nierzadkie sa przypadki, ze alpha budowala 10s (bo nie wspierana w pakiecie
> architektura), ix86 i ppc ~ 1-2h, a sparc >24h bo sie budowanie poprzedniego
> pakietu zapetlilo, a kloczek mial wolne...

Ale jeśli nie będą często wpadać sec-updates to nie powinno być
problemów. Kolejność będzie zachowana.

> > Natomiast dla pozostałych pomysł jest taki: zlecenia wysyłamy na
> > srcbuilder. Kolejność dochodzenia do niego jest obowiązująca. On buduje
> > srpm, wystawia je. 
> > 
> > Natomiast zlecenia dla innych builderów wystawia via http, wysyłając
> > tylko pocztą powiadomienie: ,,są nowe zlecenia''.
> > 
> > Po http wystwiony jest plik ze wszystkimi zleceniami z ostatnich
> > (powiedzmy) 30 dni.  Każde opatrzone numerem kolejnym, a buildery
> > pamiętają jaki był numer ostatnio przetwarzanego zlecenia.
> 
> Gdzie bedzie to http ?

Na srcbuilderze.

> Jak administrator buildera moze wykluczyc budowanie okreslonego zlecenia na
> builderze? (np. na mifgate XFree mozna bylo budowac tylko recznie,
> zatrzymujac co jakis czas budowanie - inaczej byl murowany wysyp jadra)

Samo zablokowanie to nie problem. Problem jest taki, że jeśli takie
kombinacje są potrzebne, to taki builder nigdy nie będzie w syncu z
innymi. Założenie było że budowanie pakietów jest bezobsługowe.

-- 
: Michal Moskal :: http://www.kernel.pl/~malekith : GCS {C,UL}++++$ a? !tv
: PLD Linux ::::::::: Wroclaw University, CS Dept : {E-,w}-- {b++,e}>+++ h