[SPECS] Zope i okolice

[Paweł Gołaszewski]

On Sat, 28 Jun 2003, Adam Szpakowski wrote:
> > Błąd. My wiemy dokładnie z czym dostarczamy, z jakim produktem. I nie
> > ma potrzeby, żeby to było kompilowane przy pierwszym starcie, bo nie
> > ma uzasadnienia do tego.
> Rozumiem Twe podejście, ale w przypadku Zopa jest ZTCW troszkę inna
> filozofia.  Pamiętaj, że wiele (jeśli nie wszystkie) produkty Zopa są
> zależne od innych produktów (nawet rdzeń pomijając). Są możliwe sytuacje
> gdy produkt jest kompilowany warunkowo w zależności od istniejącego
> środowiska. Zarówno ZopeBook jak i dokumentacja developerska Zopa
> wskazuje że zalecanym sposobem kompilacji produktów jest kompilacja
> przez samego Zopa przy reboocie.

To jest lenistwo.
Tak samo jak przy asterisk-u ludzie _żądają_ żeby dac jakikolwie support 
openh323 kompilowanego ze źródeł (razem z tymi idiotycznymi nazwami 
bibliotek...)

> Innym argumentem aby dostarczać produkty w postaci źródeł jest funkcja
> refresh (nakładka na reload(module) Pythona). Pozwala to w dowolnym
> momencie zrekompilować produkt z poziomu działającego Zopa. Nie każdy
> produkt jest co prawda do tego przygotowany, ale np. Plone jest.
> Przydatne jest to np. jeśli zmieniła się jakaś część składowa (np. nowa
> wersja DCWorkflows przy Plone). Oczywiście można polecieć z kolejką
> upgradów rpm-ów, ale jeśli Zope pozwala zrobić inaczej, to czemu tego
> nie wykorzystywać?

Fajnie, ale czy większości ludzi to jest potrzebne?
Pytam, bo prawie nie znam środowiska...

> Może jako poparcie mojej pisaniny dodam, że zarówno pakiety dla RH9
> (pakiet Plone) jak i dla Debiana dają źródła a produkty kompilowane są
> przez samego Zopa. Kompilowany jest tylko sam Zope (nawet nie jego
> rdzenne produkty).

To jest lenistwo ;)
Jeżeli mielibyśmy u nas się wzorować na innych distro to niewiele byśmy 
mieli ciekawego...

Możnaby spróbować wydzielić źródla do osobnego pakietu i dostarczać je, 
mając obsoletes na pakiet ze skompilowanymi wersjami. Nawet nazwać je 
*-source albo wrecz *-devel.
Jestem w stanie się założyć, że ogromna większość ludzi będzie 
potrzebowała wersji skompilowanych, bez źródeł...

> > > - Nie wymuszam restartu Zopa po instalacji nowego produktu. Jest to
> > > wymagane, ale automat jest kiepskim pomysłem. Najlepiej robić to
> > > ręcznie i świadomie.
> > Rób tak jak jest wszędzie...
> IMHO tutaj to nie jest rozwiązanie. Restart Zopa w bardziej rozbudowanej 
> konfiguracji to dosyć zamieszany proces.

To znaczy?

> Już nie mówiąc że może sporo czasu trwać.

Tak samo jak apache przy virtualkach liczonych w dziesiątkach...

> Przy instalacji kilku produktów po kolei (które co lepsze mogą jeszcze
> od siebie zależeć) robi się burdel znacznie gorszy niż przy massive
> update modułów do apacha.

To znaczy?


Disclaimer do tego posta: po parapetówce :D

-- 
pozdr.  Paweł Gołaszewski 
---------------------------------
worth to see: http://www.againsttcpa.com/
CPU not found - software emulation...