2.2 vs 2.4 -- propozycja

[Tomasz Kłoczko]

On 24 Jul 2001, Arkadiusz Miskiewicz wrote:

> pppd. Robienie bagna z rc-scripts po to by wyjaśnić wszystkim, że
> białe jest białe to lekko mówiąc przesada i ogromny błąd.
> 
> > Po oddzieleniu tego i po zmodularyzowaniu mógłbyś odzyskać
> > właściwą lekkość rc-scripts mogąć wiazać zależnościami tylko to co jest Ci
> > w danej chwili potrzebne. 
> Taka nic nie warta lekkość + koszmar w maintanowaniu rc-scriptsów. Tam
> jest tona zmiennych, różnych cudnych zależności itd. Dla mnie
> ważniejsze jest łatwość maintanowania, modyfikowania, zmiejszenia
> możliwości wsytąpienia błędów niż mówienie wszystkim że by używać ppp
> trzeba sobie pppd zainstalować.

Dokłądnie to by zostało. Dodatkowo doszłyby symlinki w repo z katalogów z 
rc-scripts do SOURCES skad pobierane byłyby juz do budowanai paakietów. 
Przykąłdowo żeby nie pzremiatać z kata w kąt tych samych zmian identyczne 
podejście jest sosoewane z polsklimi manami. Chłopaki od PTM mogą sie 
zajać wyłącznie tym co lubią/chcą.

[..]
> > Co z ATM ? też ma trafić do rc-scripts ? jeżeli tak do todatkowo 
> > rc-scripts uzaleznić bęzie trzeba od narzędzi do ATM.
> W totalnew ma trafić (i trafi).

czyli bezie kolejna niejawna zależność ..

> > Co do utrudnień i panowanai nad całoscią. Zauważ że, od dłuższego czasu 
> > interfejs miedzy obsługą poszczególnych typół interfejśów i reszta 
> > zarządzania siecią jest na tyle ustalony że wynoszenie poszczególnych 
> > kawałków po za ścisły obręb pakeitu rc-scripts moze już mieć sens.
> Tak Ci się tylko wydaje. Na HEAD jest co innego, w totalnew jest co
> innego. Z totalnew na HEAD są różne backporty (w drugą stronę
> też). Cały czas się zmienia to i owo. Jedynie opis ifcfg* w
> poszczególnych branchach w miarę jest niezmieniany. Reszta to ciąg
> zmian i modyfikacji.

Mozna sie umówić że tego typu kroki w kierunku lepszego rozseparowania 
tych zasobóe (ale pwtarzam .. w zasobach wynikowych) bęndą podejmowane po 
takie stabilizacji (?).
 
> > W tej chwili niespójnie do tego rozwiazana jest jeszcze kwestia 
> > isapnptools i setserial (pierwsze jest startowane jhako normalny serwis, a 
> > drugie jako skrypt z rc.sysinit).
> isapnptools odpalany jest bezpośrednio z rc.sysinit, a setserial
> poprzez rc.serial wywoływany z rc.sysinit. Niekonsekwencja.

Fakt tu pomyłka. hdparm podobnie. I jest to dobre zauważ dla tych tzrech 
pakietów. Odpowiednie rozszerzenia rc-scripts przychodzą z włąsciwymi 
narzędziami. To co sugeruję to w miarę możliwości poszerzanie tego 
podejścia ale w sposób lepiej kontrolowalny poprzez zmianę na w kierunku 
katalogu /etc/rc.d/rc.sysinit.d/. an pocżatek tej zmianie mogły podlagać 
wyłącznie te trzy pakeity i sam kawałek rc.sysinit. W ten sposób nie bezie 
rewoluucji i da się nad tym dalej panować.

Może rzeczywiście jeszcze na separacje skryptów do zarządznia różnymi 
typamie interfejśów sieciowych jeszcze za wczenie ale właśnie hdparm,
setserial, isapnp czy dalej raidrools, LVM, USB i IRDA, a dalej zapewne 
jakis inne rzeczy mogłby sie już rozwijać w kierunku 
/etc/rc.d/rc.sysinit.d/. Tu już nie powinno być kłopotów ze zmiana 
interfejsu na styku z rc-scripts i zmiana na potrzeby tych zasobów może 
mieć już teraz sens.

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*