CVS...

Tomasz Kłoczko kloczek w rudy.mif.pg.gda.pl
Sob, 16 Sty 1999, 04:03:18 CET


On Fri, 15 Jan 1999, Grzegorz Stanislawski wrote:

> On Fri, 15 Jan 1999, Tomasz Kłoczko wrote:
> 
> > On Wed, 13 Jan 1999, Ziemek Borowski wrote:
> > 
> > > On Wed, Jan 13, 1999 at 03:29:46PM +0100, Tomasz Kłoczko wrote:
> > > > >  Moja propozycja jest taka, zeby zrobic moduly w cvs'ie tak ja sa grupy
> > > > Dokladnie tak to widze. Takze tu sie zgadzamy.
> > > tak i nie. Bo przecież jeden spec może generować binarki i do pięciu grup. 
> > 
> > Jeżeli ktoś poda powód rozbudowy i jeżeli będzie to w jakiś sposób
> > upraszczało wszystkie operacje na tych zasobach to można wprowadzić
> > innycmodel. Jeżeli nie to powyższe stanie się regółą. Można będzie co
> > najwyżej zmienć katalog PLD na inny (rpm ? packages ?)
> >
>  Ja podam. Jest (bedzie) w dystrybucji kilka kobyl, programow ktore nie
> tylko skladaja sie z kilku binarnych pakietow, ale kilku z sorce'ow i to
> czesto roznych autorow. Dla przykladu: apache, Perl, Python, X'y (chyba),
> PAM i tak dalej.
>  Moze rzeczywiscie rozkladanie wedlug grup nie jest najszczesliwsze, ale
> samo sie nasuwa. Na razie nie widze lepszego sposobu.

Jeżeli założyć, ze spece i patche bedą miały etykiety typu
<pakiet>-<wersja>, <pakiet>-<wersja>-devel, <pakiet>-<wersja>-stable,
<pakiet>-<wersja>-last to ciągnąć w danym katalogu z etykirty zacziągniesz
wszystko to co jest do danego pakietu bez uciekania się do triku w postaci
grupowania pakietów w katalogi. Kwestia żeby ustalić taki przejrzysty
schemat etykiet, który nie tylko ułątwiać bedzie operowanie na zasobach w
trakcie normalnego developmentu ale także będzie upraszczał na maxa
automatyzację budowania pakietów.

Faktem jest, że ktoś tych etykiet będzie musiał pilnować lub bedzie moiżna
może jakieś narządka porządkujące tu porobić ale jak już etykiety będą
ładnie porozstawiane to powinno to ładnie ograniczać ilosć zasobów
ściaanych jednorazowo. Trzymanie porządku etykiet to powinno być 
zadanie dla RM.

[..] 
>  IMHO trzymanie specow osobno jest kompletnie bez sensu.

Dzisiaj zmieniłem nieco układ modułów w CVS i wyglada to teraz tak:

SPECS                   PLD-specs
PLD-doc                 PLD-doc
SOURCE                  PLD-sources
test                    test
PLD                     -a      SOURCE SPECS PLD-doc
rpm                     -a      SOURCE SPECS
ALL                     -a      PLD-doc rpm

jeżeli ktoś zrobi get ALL w ~ to dostanie następującą struktórę:

~
 \rpm
     \SPECS
     \SOURCES
 \PLD-doc

Nie wiem czy da sie coś wrzucić bez modułu (w katalog głowny) jeżeli by
się dało to zaciagając mody "rpm" czy "ALL" miałby się na dzień dobry
gotowe środowisko do dalszej roboty.

Jesli chodzi o schemat modułów i ich wzajemnego użożenia to jeszcze
kwestie nie rozwiązane to umiejscowienie yakich rzeczy jak:

- zasoby http serwera www PLD,
- moduły ze źródłąmi takich rzeczy jak adduser, pepesza, rc-scripts,
  setup.

W tej chwili to co jeszcze zostało do zrobienia w tym, próbnym
repozytorium to dorobienie notifiera na listę. Wiże sie to z posadowieniem
perla i sendmaila w chrootowym drzewku. Nie wiem czy jest to do końca
bezpieczne czy przypadkiem nie da się jakoś "przejść" pzrez cvs żeby mieć
bezpoiśredni dostęp do np. perla. Pozostała jeszcze też koncepcja
sterowania automatyzmem automatów budujacych pakiety. Zapewne bedzie to
sie odbywać przez pocztę choć może dało by się to zrobić też jakoś przez
SNMP.

Jeżeli sam układ modułow, sposób etykietowania całości, wtyczki do
automatów zostaną zrobione to można bedzie zacząć mnyśleć o zamrożeniu
całości i rozpoczęcia faktyczbnego developmenty na pałną parę. Z kolejncy
rzeczy które wypadałoby wreszcie załatwić to domena pld.org.pl i
poustawianie wszystkich adresów w niej (cvs, mail, www, ftp) i to już
zaczołem robić i moze już na początku przyszłego tygodnie bedziemy mogli
ustalać co gdzie będziemy mieli chceć mieć.

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*



Więcej informacji o liście dyskusyjnej pld-devel-pl