PLD CVS: SPECS misiek

[Tomasz Kłoczko]

On Mon, 24 May 1999, PLD CVS wrote:

> CVSROOT:	/cvsroot
> Module name:	SPECS
> Changes by:	misiek	99/05/24 15:31:11
> 
> Modified files:
> 	.              : apache.spec 
> 
> Log message:
> new - IPv6 ready apache

IMHO moduł do kerb powinien być wydzielony do osobnego modułu. Nie każdy
go potrzebuje, a po za tym konserwacja tego stuffu w osobnym pakiecie
powinna być prostrza (ma on włąsną wersję, stronę domową itd.).
Jest jeszcze jeden pozytyw tego podejścia. A mianowicie nie trzeba by
robić apache i apache z kerb gdyż rozbudowa indianina o kerb odbywałaby
się poprzez doinstalowanie odpowiednigo zozszerzenia.

Kolejna sprawa to ścieżka gdzie mają być moduły. Wg. FHS to nie jest już
/usr/libexec/apache tylko /usr/lib/apache.

Kolejne pakiety instalujące moduły żeby nie instaklować w kilku miejscach
modułów i żeby wymagać indianina szukającego modułów w konkretnym
miejscu powinny mieć w preambule:

Requires:	%{_libdir}/apache

Co do ścieżek to także mam wątpliwości czy aby obecna ścieżka w której
są trzymane pliki zbuforowane przez mod_proxy jest zgodna z FHS.

I jeszcze jedna rzecz to przyjęcie maski na pakiety z modułami do apache,
boIMHO jest ku temu i pora. W RH jest to mod_<ficzer>. IMHO powinno być
apache-mod_<ficzer> lub apache-mod-<ficzer>.
W razie gdyby taka zmiana maski na nazwy pakietów z modułami została
łyknięta to trzeba będzie dodać oczywiście w posszczególnych pakietach
odpowiednie Obsoletes.
Taka nkonwencja nazywania pakietów z modułami jest IMHO potrzebna, gdyż
zródeł z dodatkowymi modułami do indianina jest jak psów i chodzi o to
żeby te pakiety były na pierwszy rzut oka identyfikowalne.

Kolejna rzecz apropo modułów .. możnaby się pokusić o automatyczne
{de}rejestrowanie modułu instalowanego przez pakiet z modułem w
%pre/%postun z httpd.conf z restartem httpd (o ile moduł jest instalowany
przez nie z apache). Tak żeby to było takie palg'n'pluj. W tym kontekście
możnaby nawet próbować rozdzielać pakiet samego indianina na podpakiety z
modułami, których doinstalowanie dodawałoby od razu pewną funkcjonalność
(np. obsługę proxy). I tu wydaje mi się, że w przypadku przynajmniej kilku
modułów może miec to sens gdyż w wersji gołej pakiet wnosiłby małe
obciążenie w postaci wymaganej mody io zajętości pamięci, a wzbogacany
dopiero dodatkami mógłby być trochę bardziej głodomor na zasoby.

I jeszcze apropo libproxy.so to to, że gdyby ten muduł w raz z
{de}rejestracją wydzielić w osobny moduł (nie wiem nadal czy to ma sens ..
ktoś to powinien ocenić), to pakiet tak samo jak np squid może powinny
dostać:

Provides:	http_proxy

co umożliwiłoby posiadanie w systemie tylko jednego http proxy serwera.
Niewim czy to co opisałem ma sens i czy proxy indianina nie jest także
wykorzystyuwaney do jego wewnętrznych zadań umożliwiających przyśpieszanie
serwwania. Jeżeli tak jest to oczywiście powyższe nie ma sensu i może się
okazać, że instalacja i indianina z libproxy.so jako modułem (włąśnie ..
tylko ten jeden moduł nazywa się lib*, a reszta mod_*) to oczywiście
powyższe nie ma sensu.

I już ostatnia rzecz. Nie widzę na jakim użytkowniku ma chodzić httpd.
Jeżeli ma to być coś innego niż nobody (co IMHO byłoby wskazane ze
względu na możliwość wykonywania przez indianina zapisów via mod_proxy) to
trzebaby dodać w %pre useradd z utworzeniem odpowiedniego użytkownika czy
też grupy o ile będzie potrzebna takowa.

Korektę na /usr/lib/apache zamiast /usr/libexec/apache, a także korekę
%post/%preun żeby httpd był restartowany w momencie kiedy jest wykonywany
upgrade pakietu i zanbijany gdy pakiet jest usuwany zaraz wykonam ale
cała reszta wymieniona powyżej jest sprawą jeszcze do ustalenia i dopóki
się to nie wykrystalizuje pakiet pozostanie bąć tylko w repo bądz zrobię
wersję testową ale z test wywenduje aż powyższe zagadnienia zostaną
sformalizowane bąć wogóle na razie nie będę indianina ruszał (o ile nie
będę miał czasu na jego wygenerowanie).

IMHO pakiet ten można zrobić daleko lepiej niż obecnie. Można .. (?) ..
acha -> trzeba :-)

To tyle z uwag jakie mi się teraz nasuwają na czoło apropo
czerwonoskórego.

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*