skrypty builderó

[Andrzej Krzysztofowicz]

> > > 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.

> > > 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.)

> A co do skryptów -- fakt, mogą się wywalić, mogą zrobić coś dziwnego
> etc. Mogą zostać jakieś śmieci. Ale przecież dokładnie to samo się
> dzieje w wypadku ręcznego instalowania pakietów.

Ale wtedy to widzisz i mozesz recznie poprawic.
No nic, wyjdzie w praniu.

> > > 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...

> 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 ?
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)

Jesli sie nie da, to ja nie wpuszcze takiego budowania do siebie.

> Oczywiście z tym pliku opisane są również grupy zleceń.
> 
> > A gdy proces budowania jakiegos pakietu sie zapetli (zdarza sie!) na ktorejs
> > architekturze ?
> 
> Trzeba killnąć, nie wiem jaki to ma związek z doinstalowywaniem BR.
> 
> > A gdy proces budowania wymaga niepodzielnych (per chroot) zasobow maszyny,
> > jak np. pamiec wspolna, czy konkretny port TCP (problem przy wielu
> > builderach w chroot)?
> 
> Magiczny komentarz w specu. Przynajmniej będzie wiadomo które to.
> 
> > > > Poza tym, jesli takimi decyzjami ma sie zajmowac CDG, to jest to czysta
> > > > strata czasu.
> > > 
> > > IMHO CDG może zatwierdzić tylko ogólne założenia.
> > 
> > Wlasnie.
> > A kto te zalozenia powinien wyartykulowac? Cezar? ;_)
> > Nie widzialem jeszcze kandydatur na RM. A umiejetnosci tych osob sa
> > baaaardzo wazne.
> 
> Ja mogę zrobić skrypty, na RM się nie nadaje.

Masz propozycje ?
Mam niejasne wrazenie, ze bedzie to osoba "z lapanki" :(
I po co byla ta cala nieprzygotowana "rewolucja"...

-- 
=======================================================================
  Andrzej M. Krzysztofowicz               ankry w mif.pg.gda.pl
  phone (48)(58) 347 14 61
Faculty of Applied Phys. & Math.,   Gdansk University of Technology