Jak to w th będzie (

[Andrzej Krzysztofowicz]

Mariusz Mazur wrote:
> On poniedziałek 07 marzec 2005 14:32, Andrzej Krzysztofowicz wrote:
> > IMO wprost przeciwnie. Powodowaloby niwelacje roznic pomiedzy builderami.
> > Zakladam, ze mechanizm bylby taki:
> >
> > 0. wyinstalowanie _wszystkiego_ oprocz listy ustalonych, nieruszanych
> > pakietow 1. doinstalowanie zaleznosci
> > 2. zbudowanie
> > 3. odeslanie wynikow
> >
> > Bez tej dodatkowej opcji punktu 0. by po prostu nie bylo.
> > A punkt ten powodowal by "wyczyszczenie" builderow.
> 
> Ja to czarno widzę na wolniejszych maszynach, zwłaszcza w przypadku programów  
> o sporych zależnościach. Acz ciekawe by było, jakby ktoś to spróbował zrobić.

Trzeba by sprawdzic na takim ppc...

> > > Inna sprawa, że nie wiem po co to miałoby być?
> >
> > Np. masz 2 pakiety, ktore maja rozne, wzajemnie konfliktujace BR.
> 
> Ile takich mamy?

Dwa nie wystarcza czesto przebudowywane ?
W Ac o to sie rozbilo przebudowywanie wsparcia dla modulow Apache::* w
Perlu. (jedne wymagaja apache-mod_perl, inne apache1-mod_perl)

> > Trzecim moze byc sprawdzenie czy nie brakuje BR (ale to, jesli sie buildery
> > nudza).
> 
> Coś takiego to można by było zrobić niezależnie (jakaś jedna maszyna iterująca 
> się po wszystkich pakietach z Ac i próbująca je zbudować w ten sposób).

A nie byloby fajnie gdyby ta maszyna dzialala w wykorzystaniem automatyki
buildera po prostu?

> > A jakbys chcial potestowac zestaw pakietow, ktore wzajemnie od siebie
> > zaleza (tzn. te, od ktorych zaleza tez wymagaja testowania) ?
> > Np. cale kde...
> 
> No niestety podstawowym priorytetem jest robienie danej dystrybucji, a nie 
> testowanie dziwnych rzeczy. Do bardziej kompleksowego testowania (wymiana 
> większej ilości podstawowych pakietów), to niestety są potrzebne jakieś 
> nesty. I tutaj nie ma różnicy, czy Ac, czy Th.

Totez sugerowalem: buildery testowe==odrodzony nest ;P

> Przy czym, gdybyśmy używali instalowania brów przy każdym budowaniu, to to by 
> miało sens.
> 
> > Jesli bedzie zapotrzebowanie, to sie znajda.
> > Oferowalem swego czasu udostepnienie 30 maszyn w godzinach
> > wieczorno-nocnych...
> 
> Przydałoby się, żeby znalazł się chętny do popróbowania tego budowania z 
> brów :)

Jest kto chetny do postawienia tego?

> > Sprawdzales jaki % czasu buildery sie nudza?
> > Mogly by sie zajac czyms pozytecznym w wolnych chwilach.
> 
> Niestety nie dysponuję danymi statystycznymi, acz planuję znacznie ożywić 
> zainteresowanie robieniem distro przy Th (ac popada w marazm), więc bardziej 
> obawiam się niedoboru mocy obliczeniowej (zwłaszcza przy alphie i sparcu), a 
> nie vice versa.

Najwolniejszy builder w Ac nudzil sie pewnie ze 30% w skali roku.
Co nie znaczy, ze ten czas daloby sie lepiej wykorzystac.

> > A jak to nie jest snapszot tylo pelna wersja, ktora podobno niektorym nie
> > dziala i ktora probuje poprawic. I nie chce, zeby rm (gdy juz wroci z
> > balangi/delegacji/wakacji) i wezmie sie za porzadki ja przeniosl? (Nie
> > wiem, czy mnie zapyta, czy przeczyta poczte itp.)
> 
> Rm jeśli zobaczy starą paczkę, to będzie męczył autora zlecenia. Jeśli ten nie 
> zareaguje, to paczka pójdzie do /dev/null -- nie będę ryzykował przenoszenia 
> jakiejkolwiek paczki na chybił trafił, to już lepiej, żeby tej paczki w ogóle 
> nie przenosić.

Chodzi o to, czy po zbudowaniu nowszej wersji starsza nie trafi do /dev/null
automatycznie. Chodzi o to, zeby _nie_ trafila.

> > Poza tym w test juz lezy poprzednia pelna wersja, ktora wlasnie czeka na
> > przeniesienie (mips konczy ja budowac).
> >
> > Fantazjuje? Wcale nie. Byly takie przypadki w Ra.
> 
> Nie rozumiem prawdę mówiąc w czym problem.

Patrz poprzedni akapit. Moze rzeczywiscie nie ma problemu. W Ra/Ac(troche)
byl.

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