Nowy PgSQL (Bylo: Re: PostgreSQL i polskie zarosla)

Jakub Bogusz qboosh w pld.org.pl
Nie, 3 Mar 2002, 00:59:48 CET


On Fri, Mar 01, 2002 at 05:05:39PM +0100, Blues wrote:
> On Fri, 1 Mar 2002, Jakub Bogusz wrote:
> > > > 2. Przy upgrade hurtowo: postgresql-libs, postgresql-devel,
> > > >    pstgresql-clients i postgresql (jednoczesnie), wszystkie sie
> > > >    aktualizuja, oprocz postgresql (pisze i dumpie itd.)
> > > >    i postgresql-devel (krzyczy, ze mu sie biblioteki nie zgadzaja).
> > > >    W rezultacie zostajemy z nowymi bibliotekami, nowymi klientami, ale
> > > >    ze starym serwerem. Mam tylko nadzieje, ze nowy pg_dumpall nie
> > > >    psuje dumpow ze starego serwera...
> > > To jest problem (już pisałem o tym) z rpm'em.
> > > Musiałby on obsługiwać coś na kształt ServiceGroup: postgresql
> > > Wtedy można było dać %pregroup to co jest teraz w pre samego servera...
> > Nie, tu jest akurat trochę inny problem:
> > 1. to o czym niedawno pisałem - rpm sprawdza zależności tylko przed
> > instalacją grupy pakietów (trzeba sprawdzić, czy w 4.0.4 coś z tym
> > zrobili)
> 
> Tu jest ten sam problem (a w zasadzie jego rozwiązanie). :)

Workaround a nie rozwiązanie :)

> Zauważ, że rpm przy istnieniu grup musiałby najpierw sprawdzać zależności 
> od grup. I wtedy jeżeli w %pregroup byłby warunek taki jak teraz mamy 
> w normalnym %pre to _cała_ grupa by musiała wylecieć podczas instalacji... 
> Ja tutaj nie widzę innej możliwości.
> 
> Inna sprawa, że wymagania pamięciowe rpm'a by wzrosły trochę.

rpm się robi coraz bardziej transakcyjny - może w 4.0.4 już instalacja
grupy pakietów może być pojedynczą transakcją?
Instalowanie "wszystko albo nic" rozwiązałoby problem psucia zależności,
a i grupowanie do skryptów byłoby łatwiej dorobić.


-- 
Jakub Bogusz    http://prioris.mini.pw.edu.pl/~qboosh/



Więcej informacji o liście dyskusyjnej pld-devel-pl