Buildery

[Witold Filipczyk]

On Mon, Jan 13, 2003 at 10:59:02PM +0100, Tomasz Kłoczko wrote:
> On Mon, 13 Jan 2003, Witold Filipczyk wrote:
> 
> > On Mon, Jan 13, 2003 at 08:24:02PM +0100, Tomasz Kłoczko wrote:
> > > On Mon, 13 Jan 2003, Witold Filipczyk wrote:
> > > [..]
> > > > zmiana w CVSie (zmiana Release || zmiana Version || coś jeszcze) -> request SRPM
> > > 
> > > Wybacz le nie jest w tej chwili kluczową kwstia to żeby budować pakeit po 
> > > każdej zmianie rel,. Kluczowe jest wszystko to co ma się dziać *PO* 
> > > zbudowaniu pakewitu kiedy tak jak teraz leży on juz w test.
> > 
> > Dla mnie jest istotne, żeby każdy nowy pakiet, pakiet z podbitym rel, itp.
> > był budowany.
> 
> Uwierz mi .. to nie jest kluczowe. Popatrz na Nest. Tutaj moze 
> powstawać conajmneij tyle pakietów ile powstawało w Ra. Dlaczego nie 
> powstaje ? Anio dlatgo, że newralgiczna czynnościa nei jest tu wysłanie 
> kilku setek zleceń tylko obrobienie tego wszyetkiego co w wyniku tychże 
> zleceń powstało.
> 
> Ważne jest i także to żeby przed puszczeniem pakietu miały szansę
> przejrzeć go conajmnij kilaka osób. Jeżeli commit będzie generował sygnał
> do przebudowania to tą sznsę odbierzesz wszystkim w z buildeów bedzie
> wychodzić kupę sieczki której nikomu nawet nie bedzie chciało się dotykać
> (a zmian wprowadzanych w osaniej chwili było zawsze dosć sporo o ile widać
> było że szykuje się kolejne rel pakietu).

To nie było kluczowe, bo opóźniało co innego.  Mogą to przejrzeć
po przebudowaniu pakietu, mając do dyspozycji dodatkowo logi z budowania.
Jeśli coś będzie nie tak, wyrzucą pakiet z test.
Możliwość podłożenia trojana jest czysto
teoretyczna, bo musiałby to zrobić ktoś kto ma dostęp do CVS, a tych nie jest
dużo. Osoba taka musiałaby mieć jakiś motyw (zakładam podobnie jak
we wszystkich filmach kryminalnych, że motyw musi być).  Także pakiet jest
jeszcze w kolejce do przebudowania można go przejrzeć i ewentualnie wyrzucić.

Przedstawiony przeze mnie schemat jest prosty (ktoś mówił coś o KISS).
ACLe, podpisy, itd. nie wnoszą nic jeśli chodzi o bezpieczeństwo, bo
gdy builder zostanie zdobyty (zhackowany) wszystkie klucze zostaną przejęte
i włamywacz będzie mógł "wyprodukować" takiego rpma jak będzie chciał.

Z tego co rozumiem najtrudniejsze jest przenoszenie pakietów z test na główne
drzewo. Chodzi o to, żeby zawartość głównego drzewa na FTPie zawsze
nadawała się do instalacji i generowania iso.
Proponuję tak:
Pakiety, które są gotowe, żeby je przerzucić są przenoszone do katalogu
DO_PRZERZUTU.
Z każdą architekturą kojarzymy bazę RPMową.  Do przenoszenia
pakietów wykorzystamy poldka.
poldek ma między innymi takie opcje jak:
-dumpn  - wypisuje, które pakiety będą zainstalowane
-justdb - uaktualnia tylko bazę RPMa, nie instalując pakietów
Ma też ciekawą opcję konfiguracyjną keep_downloads. 
Opcja -dumpn też jest ciekawa, ale się tu nie przyda.
Po prostu będziemy robili upgrade w połączeniu z -justdb
i download=yes, a katalog cache, do którego będą ściągane pakiety,
to będzie nasz katalog z RPMami.

Załóżmy, że nie ma żadnych konfliktów między pakietami, żadnych Obsoletes.
Upgrade jest trywialny w takiej sytuacji.  RPMS to katalog docelowy.
$ poldek --install cośtam --justdb --cachedir=RPMS
Do katalogu RPMS zostaną skopiowane potrzebne pliki.  Baza RPMowa zostanie
uaktualniona.  Trzeba jeszcze skasować stare wersje.
$ rpm -qa | sort   da zainstalowane pakiety
$ ls  da wszystkie pliki.
$ comm da różnicę, którą można skasować.

W przypadku, gdy są Obsoletes dla każdego pakietu "Obsoletesującego", tworzymy
oddzielną bazę rpmową.  Z każdą taką bazą stowarzyszamy grupę.  W skład grupy
wchodzą pakiety, którą zostały "zainstalowane" w danej bazie.

Mam plik group "odwrotny" do /etc/group.  Ten plik trzeba mieć, trzeba go zrobić
ręcznie
np.
postfix:postfix
kernel:main,postfix,exim, itd.

itd.
Dla każdego pakietu - lista grup do których pakiet należy.

Upgrade pakietów na FTP będzie polegał na:
a) skopiowaniu wszystkich baz do "tmp"
b) instalujemy pakiet we wszystkich grupach, do których należy
c) jeśli wszystkie instalacje zakończyły się pomyślnie goto e)
d) przywracamy starą bazę
e) kasujemy "osierocone" RPMy, których nie ma w żadnej bazie  

Pakiety pomyślnie zainstalowane kasujemy z katalogu DO_PRZERZUTU.
A jednak przyda się opcja -dumpn.

Sorry, że piszę tak rozwlekle.
Mam nadzieję, że piszę dość jasno jak na pierwszy mejl na ten temat.

Dalej nie rozumiem w czym problem.

-- 
Witold Filipczyk
<witekfl w poczta.onet.pl>