glibc na ftp nowszy niz w cvs ?

[Tomasz Kłoczko]

On Fri, 8 Sep 2000, Roman Niewiarowski wrote:

> Hejka
> 
> komus sie palec omsknal i na ftp.pld.org.pl jest
> glibc-2.1.91-0.8.i686.rpm
> z tego co widze w cvs to powinien byc 2.1.3-19

E .. troche mało widać sie przyglądałeś temu co jest w CVS :_)

[kloczek w cenzor SPECS]$ cvs status -v glibc.spec
===================================================================
File: glibc.spec       	Status: Up-to-date

   Working revision:	1.122
   Repository revision:	1.122	/cvsroot/SPECS/glibc.spec,v
   Sticky Tag:		(none)
   Sticky Date:		(none)
   Sticky Options:	(none)

   Existing Tags:
	glibc-2_1_3-19           	(revision: 1.121)
	glibc-2_1_3-18           	(revision: 1.118)
	glibc-2_1_3-16           	(revision: 1.115)
	glibc-2_1_3-7            	(revision: 1.108)
	glibc-2_1_3-6            	(revision: 1.107)
	glibc-2_1_3-5            	(revision: 1.106)
	glibc-2_1_3-4            	(revision: 1.105)
	GLIBC_2_2                	(branch: 1.97.2)
	glibc-2_1_3-2            	(revision: 1.91)
	glibc-2_1_2-13           	(revision: 1.78)
	glibc-2_1_2-12           	(revision: 1.75)
	glibc-2_1_2-11           	(revision: 1.73)
	glibc-2_1_2-8            	(revision: 1.65)
	glibc-2_1_1-5            	(revision: 1.61)
	glibc-2_1_1-4_1          	(revision: 1.58)
	glibc-2_1_1-4            	(revision: 1.51)
	glibc-2_1_1-1            	(revision: 1.38)
	glibc-2_1-10             	(revision: 1.19)
	rpm3                     	(branch: 1.18.2)
	glibc-2_1-9              	(revision: 1.18)
	glibc-2_1-8              	(revision: 1.14)
	glibc-2_1-7              	(revision: 1.13)
	glibc-2_1-4              	(revision: 1.9)
	STABLE                   	(revision: 1.121)

jak widzisz na tym samym obiekcie w cvs jest kilkaset wersji tego
pliku. Wszystkie one nie tworzą ciagu tylko drzewko zmian (główna
"gałąź" zmian i dwa odgałezienia).
Kiedyś spece były szykowane do tego żeby można było używać ich z użyciem
rpm-a 3.0.x i ślady szykowania tych wersji są na branchu rpm3.
Teraz na branchu GLIBC_2_2 jest wersja rozwojowa glibc (obecnie
2.1.91-0.8).

Jeżeli zapuścisz buildera przez:

[SPECS]$ ./builder -g glibc.spec

to ściafniesz źródła bierzącego glibc. Jeżeli:

[SPECS]$ ./builder -g glibc.spec -r GLIBC_2_2

to dociagniesz wersję 2.1.91-0.8.
Dokładnie każda inna etykieta z powyższych moze być wykorzystana w
analogiczny sposób po to żeby dociagnąć zasoby które były w konkretnej
chwili.

Glibc 2.1.91-0.8 zostało próbnie wygenerowane i leży sobie w /test na
potrzeby osób które będą chciały/potrzebowały poeksperymentować sobie z tą
wersją (sama kompilacja troche zajmuje i jej koszt jest znacznie większy
niż koszt przechowywania gotowego do użycia pliku który lezy sobie na ftp.

Speców czy ogólenie plików które mają w repo branche jest trochę. Np. w
repo leży też wersja kernela oparta o źródła 2.4.x. W pewnym momiencie
kiedy zdecydujemy że bedziemy juz chcieli przejść na np. glibc 2.1.9x czy
kernel 2.4 nie beziemy musieli od podstaw opracowywać znowu speców dla
tych wersji. Wystarczy że odpwoeidnie wersje speców i innych zasobów z
odpwoednich branchy zostaną zintegrowane z etykietą pływającą HEAD (czulu
głównym odgałęzieniem zmian).
Mówiąc inaczej .. to że w tej chwili bazujemy na glibc 2.1.3 czy kernelu
2.2 nikogo nie blokuje przed próbami preparowania zasobów juz pod następne
generacje tych zasobów.

Tak czy inaczej masz okazję przekonać się na czym polegają pewne niuanse
zwiazane z specyfiką/zaletami pracy opartej o CVS :)

Jeszcze jedna uwagas. Etykieta STABLE jest przypisana do punktu w którym
zasoby zostały zebrane po to żeby wyprodukować pakiet który leży obecnie
na ftp i po przy każdym puśzczeniu pakietu na builder po to żeby uzykać
zasób który ma sie potem znaleźć na ftp ta etykieta jest przesuwana (robie
to sam używajac neico zmodyfikowanej wersji skryptu builder [1]). Jeżeli w
tej chwili być wykonał np. w SPECS:

[SPECS]$ rm -f *; cvs up -r STABLE

to dociagnołbyś tylko te spece które taka etykietę maja i w wersjach jakie
były użyte do wygenerowania pakietu który leży na ftp.

[1] tej modyfikacji (obsługi przełacznika -T/--tag nie włączyłem do
buildera w cvs żeby nie prowokować do przesuwania etykiet pzrez osoby
które nie mają za bardzo orirentacji w tym co mogą popsuć .. bo etykiety w
każdej chwili można przesuwać) .. i proszę nie mieć o to pretensji że tak
własnie postepuję. Jeżeli kiedykolwiek zdaży się, że sam z jakis powodów
np. czasowo będę musiał zrezygnować z swego rodzaju nadzoru tych zasobów
od tej strony po to żeby pałeczkę przekazać komuś innemu to ta osoba
dostanie odemnie buildra z poprawką która automatyzuje etykietowanie.
Będzie bardzo dobrym zwyczjem jeżeli nadal niezależnie od tego kto to
będzie robił takie decyzje co etykietowania bedą podejmowane jedno lub
maks dwu osobowo. Pluralizm w takch przypadkach komplernie się nie
sprawdza .. z czego mam nadzieję wiekszość tutaj doskonale zdaje sobie
sprawę albo jak kto woli obecny model załatwiania tych rzeczy zdaje
całkiem dobrze egzamin.

Tak czy inaczej :) .. proszę zapomnieć, że w stosunku do zasobów w
modułach SPECS, SOURCES można użyć "cvs tag". Jeżeli odkryję, że ktoś
grzebie przy etykietach to bedzie źle ;> .. bo będzie trzeba wymyślać
mechanizm jak to blokować (a to byłaby niepotrzebna strata czasu którego
nie mamy za dużo).

kloczek
-- 
-----------------------------------------------------------
*Ludzie nie mają problemów, tylko sobie sami je stwarzają*
-----------------------------------------------------------
Tomasz Kłoczko, sys adm @zie.pg.gda.pl|*e-mail: kloczek w rudy.mif.pg.gda.pl*