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 [EMAIL PROTECTED] phone (48)(58) 347 14 61 Faculty of Applied Phys. & Math., Gdansk University of Technology _______________________________________________ pld-devel-pl mailing list [email protected] http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
