User postgres

[Wojtek Slusarczyk]

On Sat, 16 Jan 1999, [ISO-8859-2] Tomasz Kłoczko wrote:

> I co z tego, że usuniesz tego DoS kiedy dalej będziesz(my) tracił kupę
> czasu na SbO ? Zrozum, że apeluję o zaprzestanie niepotrzebnych działań,
> działń które pochłaniają cenny czas, które utrudniają w tej intensyfikację
> nad PLD wspólnie w devel i stable, które czynia proces przechodzenia
> pakietów z devel do stable trudnym .. cztaj: czas poświęcony na deve
> trzeba jeszcze pomnoeyć przez 1.x (x bliskie 9), żeby uzyskać pakiet do
> stable. W tej cwili stawiam poprostu pytanie o sens pewnych działań, o to
> czy obecny dualizm cxzemuś wogóle służy, czy PLD to są dwie dystrybucje
> czy jedna w duch odmianach (produkcyjnej i rozwojowej).

Wczoraj jakos uszedl mi uwadze ten fragment wiec dzisiaj bedac wypoczetym
sie do niego ustosunkuje.

1. W develu nie musimy juz tracic cennego czasu na ustawianie odpowiednich
atrybutow na binarkach i plikach systemowych, poniewaz to zostalo zrobione
do konca na przelomie listopada/grudnia zeszlego roku.

2. Kiedy zaczynalismy prace nad Tornadem, w okolicy sierpnia przezylem
piewrwszy szok gdy zapadla decyzja o przenoszeniu %changeloga na koniec
speca .... nic zostalo to zrobione.

3. We wrzesniu ponownie doznalem 'wstrzasu' kiedy zapadla decyzja o
stosowaniu %defattr(644,root,root,755) -- nic tam, wszystko zostalo
przeprawione zgodnie z obowiazujacym standardem ...

4. Pod koniec wrzesnia zapadla decyzja o 'wdrazaniu estetyki specow'
(a mielismy juz na devel kilkaset pakietow !) Wszystko zostalo przerobione
i wyrownane i wypolerowane tak, ze teraz stable (bez obrazy oczywiscie
...) jest w porownaniu z develem niechlujny i nieczytelny (za wyjatkiem
moze 5-10 % pakietow).

5. Kolejna sprawa to so-linki manow... Poszedl rozkaz aby
wywalac symlinki bo to sie pozniej przyda do kompresji ... Nic tam
rozpakowano kilkaset pakietow i stopniowo (3-4 tyg. dokonano zmian) ...

6. Poszedl kolejny 'prikaz' ze dla zachowania zgodnosci ze stable i dla
oszczedzenia miejsca na dysku trzeba kompresowac many ... uff.. O.K jak
kompresowac to porzadnie, czyli bzipem ... nikt oczywiscie o tym nie
pomyslal wczesniej a i teraz jakos do bledu nik nie chce sie przyznac i
nadal w stable many sa kompresowane malo-wydajnym (w porownaniu z bzipem)
gzipem ... ale to juz nie moja dzialka ...

7. Niedawno dodatkowe rozporzadzenie traktowalo o 'nowym standardzie' 
wprowadzania *.info w skryptach %post i %pre .... nic nie powiedzialem i
jak moze zauwazyles wszystko jest stpniowo i z rozwaga portowane ze stable
do devela ....

Jak mnie pamiec nie zawodzi latem zeszlego roku byla rozmowa na temat
sensu istnienia devel'a. Z ustalen wynikalo, ze to bedzie taki rawhide
dla PLD i tam wszystkie nowe oprogramowanie bedzie testowane, przy czym
jak sie nie sprawdzi (czyt. beda opory np. z binarkami o atrybutach 711)
to takie rowiaznie ma nie wejsc do stable i kropka. 

Jak zdazylem zauwazyc ostatnimi czasy cale PLD zostalo postawione na
glowie, tzn. awantra jest o to ze na develu sa binarki 711, 4710 i masz
problemy potem z przeniesieniem tego na stable ... Generalnie IMHO sprawy
powinny wygladac tak, ze to my biezemy ze stable pakiety i na podstawie
specow stablowych generujemy pakiety dla devela. I owszem na poczatku tak
bylo wszsystko zostalo pobrane ze stable, SRCRPM'y wyczyszczono
doszczetnie incoming cenzora ( do tej pory co dziennie jest
sprawdzany czy nie ma nic nowego jak rowniez /test i nowe src.rpmy). 
Wszystko co sie pojawi na anonsie CVS jest skrzetnie odnotowywane i to co
Ty poprawiasz dla stable w przeciagu kilku godzin znajduje sie rowniez w
develu (a co jest oczywiscie rozsadne...) Czyli z mojego punktu widzenia
sprawa wyglada tak, ze devel caly czas obserwuje co sie na stable dzieje i
jakie pakiety wchodza do incominaga weryfikujac pewne rzeczy, natomiast
"stable" wyklada laske na devel i jeszcze opier*** ze na binarkach jest
711 i to jest security by obscurity, i wogole, ze sa remote exploity na
Tornado i ze  lepiej zrobic tak jak na stable czyli 'wypiac tylek' i
narysowac na nim tarcze strzelnicza .. (czyt. zachowac uprawnienia jakie
sa proponowane dla stable ...)  A przeciez byla mowa, ze devel robi
'experymenta' i jak nie wypali jakies rozwiazanie to nie wchodzi do 
stable ...

Dalej wracajac do stable ... dawno skonczyl sie juz na nim zapas
zrodel (czyt. wszystko co bylo mozna i nie tylko zostalo przeniesione do
devela) i teraz sami juz musimy sie troszczyc o nabywanie nowych pakietow.

Co wiecej uwazam ze na develu sa zachowane wszelkie standardy odnosnie
wygladu specow (odstepy, wyrownania, %defattr(644,root,root,755, itp.) 
Jak na moj gust przekompilowanie pakietu na stable wiaze sie ze zmaina
atrybutow, czyli przy naszej rozpisce uprawnien jest to mniej wiecej
cosik takiego:

-%attr(711,root,root) /usr/bin/aaabb
-%attr(711,root,root) /usr/bin/bbcc
-%attr(711,root,root) /usr/bin/ddee
-%attr(755,root,root) /usr/bin/ffee.sh

+%attr(755,root,root) /usr/bin/*

Dalej odnosze wrazenie, ze olewane sa dokladnie pakiety z devela i raczej
stable jest wzorowane na poczynaniach rawhide'a (przyklad z bashem)  ;(

W tej chwili pozostala nam jeszcze jedna rzecz czyli dokladna rozpiska
grup Admin, Libraries, Base itp. co ulatwi zycie chlopakom od instalatora
oraz dokladne i szczegolowe okreslenie przynaleznosci katalogow do
poszczegolnych pakietow (dla plikow  to juz prawie w 100%
zostalo zrobione)... Oczywiscie nie da sie tego tak 'hop siup' zalatwic
dlatego kazdy pakiet jeszcze szczegolowo kontrolowany pod kontem innych
np. setup, filesystem itp ... Wiekszosc pakietow i ich katalogow jest juz
okreslona zostaly najwieksze landary typu TeX (poprawiany w tej chwili), 
X'y (raczej poprawnie ale trzeba jeszcze kilka katalogow przydzielic),
Xemacs, emasc -- podczas upgrade zostanie zalatwione .... 

Przyznam, ze jestem troche rozczarowany Twoja postawa i stosunkiem do
devela i jego pakietow... Zrola devela juz kilka razy byl rozpakowywane
doszczetnie i kazdy doslownie _KAZDY_ spec poprawiny po kontem nowych
dyrektyw -- slysznych zreszta, wprawdzie ja mam zawsze opory do zmian 
ale musze przyznac ze raczej wszsytkie Twoje decyzje byly dobre (za
wyjatkiem gzipowanych manow i uprawnien 644 na plikach konfiguracyjnych)
Jak siegne pamiecia, ile czasu sie wkurzalem, ze wszsytko co nowe
sh-utilsy, apache, kde idzie tylko do incominga stable a na devela lache
wykladaja i we dwojke z Marcinem musimy ciulac pakiety i patrzec czy sie
jeszcze ktory nie pierdykne gdzies ... Ale nadeszly i dobre czasy kiedy
devela zaczal poprawiac Ziemek z Arkiem ... Zauwaz ile poprawek
zwiazanych z poprawnoscia funkcjonowania zostalo zrobionych od grudnia...

A z reszta koncze ten dlugawy list i mam ndzieje, ze nie zrozumiesz mnie
zle, ale myslalem ze devel ma wygladac, tak samo jak stable (czyt. te same
pakiety + nowe ) i to my mamy testowac wszelkie zachowania nowych
programow i podpowiadac co ma a co nie wrzucone do stable, stable
developerzy natomiast wprowadzja/nie wprowadzja rozwiazan z devela ale
nigdy mi sie nie przysnilo ze mam robic pakiety w ten sposob zeby byly
tylko i wylacznie do uzytku na stable a olac cala kupe zawilych zaleznosci
na rodzimym develu i nie przjmowac sie nim -- niech bedzie bajzel na
Tornadzie to nie wazne najwzniejsze aby stablowcy mogli sobie pobrac
pakiet. dopisac do %changeloga:

- minor changes,
- build against PLD-stable,
- standarized %prep && %build .

i wykonac rpm  -ba *.spec ... A jak cos nie tak to opier*** nas zesmy lipe
wypuscili i wogole ...   
 
na gazie,
-- 
Wojtek Slusarczyk (091)4494148
Technical University of Szczecin
PGP KeyServer pgpkeys.mit.edu