Błąd w slocate

Tomasz Kłoczko kloczek w rudy.mif.pg.gda.pl
Pon, 21 Cze 1999, 13:07:59 CEST


On Mon, 21 Jun 1999, Wojtek Slusarczyk wrote:

> On Mon, Jun 21, 1999 at 11:55:04AM +0200, Tomasz Kłoczko wrote:
> > Dopóty dopóki  pakiet nie wychodzi z CVS nie ma po co się chwytac
> > półsirodków. To co preferujesz to jest dodawanie dodatkowej roboty.
> 
> Uff..
> 
> To nie jest półśrodek ani dodatkowa robota, łatwiej po prostu
> jest teraz dodać /usr/bin/update-db -- co jest odzwierciedleniem
> pakietów, które są w danej chwili w CVS (glibc-2.1.1-4?) i pod tym kontem
> wszystko jest funkcjonalne, niż robić bez /usr/bin/update-db ...
> 
> Mówisz, że Janek zrobi .. a jak nie zrobi ? 
> 
> Latwiej jest dodać/usunać /usr/bin/update-db, niż zaplombować shadow,
> i czekać na nowe, zaplombowane shadow ..
> 
> Rationale :
> 
> Każdy kto robi poprawki w pakietach IMHO powinien sam go przetestować:

Zanim się weź=mie za modyfikowanie powinien przemyśleć to co chce
zmodyfikować.

Zauważąsz to, że przy ręcznym używaniu useradd będziesz _musiał_ pamiętać
o tym żeby zaktualizować ręcznie bazy ? Kolejna rzecz .. każdy z tych
czterech programów to pewien schemat. Wystarczy, że ktoś zrobi jeden z
nich, a opracowanie pozostałych będzie mogła zrobić osoba o znacznie
mniejszych kwalifikacjach w temacie. Nawet jeżeli Janek nie bedzie miał
czasu lub mu się poprostu nie bedzie chciało (nic go tu przecież nie
zobowiązuje) to IMHO warto żeby ktoś nawet kompletnie nieprzygotowany do
tematu PAM zrobił to od podstaw .. zwróci się to z nawiązką (zapomnimy o
pewnych upierdliwych szczegółach związanych z modygikacją nbazy
użytkowników i grup) i będzie kolejna osoba która będzie się w tym już
dość lepiej orientować. Modyfikacje do PAM to nie są rzeczy których nie
dałoby się opanować w dzień czy w dwa, a Janek znając lepiej temat mógłby
tylko zrobić to tylko szybciej.

Jeżeli jesteś niecierpliwy to mozesz sie wyżyć prubując wcisnąć się w
temat. Nie zrobisz tego Ty zrobi to krtś inny .. i tak będzie taniej i
szybciej, a efekt końcowy będzie poprawny.

> czyli przebudować, zainstalować-odnstalować-zainstalować(ponownie) sprawdzić
> podstawową funkcjonalność (komendy opcje itp.) Dopiero po takim teście wrzucać
> do CVS'a i tego samego taka osoba wymaga od innych developerów -- tzn trzeba
> mieć pewność, że podstawowa funkcjonalność jest zachowana -- ja po prostu nie 
> wyobrażam sobie systacji, że ktoś robi poprawki w specach i nie testuje 
> (na własnym tyłku) tego co zrobił a pacha w świat pakiet szukając 
> "Łosi" którzy zrobią to za niego ...  
> 
> Jeżeli ja robię PLD to robię to na pakietach które są w CVS, po to aby 
> wyłapać wszystkie grubsze błędy (drobnych nie da się tak łatwo) ...

Nie! .. kurcze nadal nie rozumiesz znaczenia CVS i to po mimo tego że
używasz tego chyba już z pół roku. To są zasoby robocze. Zasoby pracujace
to te które w tym wszystkim są oetykietowane i puszczone na zewnątrz. Tu
się może dziać dużo i po każdej zmianie zasobów nie koniecznie między
każdą zmiana wszystko musi działać.

> Ignorowanie tego co napisałem powyżej po prostu wylezie podczas składania
> wszystkiego w całość czy prób instalacji/upgradu ... I będzie bardziej
> uciążliwe niż się może w tej chwili wydawać ...

Kolejny raz nie Wojtek .. ignorowanie tego co chcesz uważać za mało
znaczące i w tym wypadku możliwe do rozwiązania półsirodkiem to jest
(nazwę to po imieniu) brak umiejętności patrzenia trochę dalej po
za zasięg włąsnego nosa lub jak wolisz głupota, która nic z racjonalnym
działaniem nie ma wspólnego .. to jest tylko motanie się od przypadku do
przypadku .. od łąty do łaty łatającej łatę.

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