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