On Thu, Sep 27, 2012 at 03:21:12PM +0200, Jakub Bogusz wrote: > On Tue, Sep 25, 2012 at 12:29:38PM +0200, zawadaa wrote: > > commit 9214a4d4c6913380a9e02edb10cf81acca08ee45 > > Author: Andrzej Zawadzki <[email protected]> > > Date: Tue Sep 25 12:22:51 2012 +0200 > > > > - initial support for full pg_upgrade > > - exmaple: > > pg_upgrade -b /usr/lib64/postgresql-9.1/bin/ -B /usr/bin/ -d > > /var/lib/pgsql/data -D /var/lib/pgsql/data_new > > - I don't know is this propoer packaging - looks ugly - please review > > - NOTE: this can upgrade from 9.1 to 9.2 only! > > Parę pytań. > Co dokładnie jest potrzebne pg_upgrade ze starej wersji postgresql-a?
Binarka serwera i wszystkich modułów (w tym zewnętrznych) które były używane przez upgrejdowaną bazę. Ten pg_upgrade działa tak, że uruchamia stary i nowy postgresql (na zmiane) i dane z jednego przesyła do drugiego. Niespecjalnie mi się to podoba, ale to na razie najlepsze co PostgreSQLowcy wymyślili. > Czy obsługuje tylko poprzednią wersję, czy także wcześniejsze? „pg_upgrade supports upgrades from 8.3.X and later to the current major release of PostgreSQL, including snapshot and alpha releases.” Więcej tu: http://www.postgresql.org/docs/9.0/static/pgupgrade.html > Mi też się nie podoba ten sposób budowania. Z tego co widzę - pg_upgrade > do zbudowania nie potrzebuje niczego ze starszej wersji postgresql-a > - więc nie ma powodu, żeby budować ją jednocześnie. Racja. > Widziałbym raczej postgresql9.1.spec (ew. też postgresql9.0.spec itd., > w ramach wersji obsługiwanych przez pg_upgrade) - i stamtąd budowany > pakiet np. %{name}-upgradesource czy %{name}-dump (w zależności od tego, > co to naprawdę robi), ew. jakieś inne podpakiety, jeśli ktoś potrzebuje. Najlepiej byłoby móc zachować binarki z poprzedniego buildu - bo tego właściwie oczekuje pg_upgrade… ale nie widzę jak to by miało działać z dystrybucyjnymi pakietami (zależnościami ciągniętymi przez upgrade). Myślę, że najrozsądniej byłoby gdy wychodzi nowy postgresql robić tak: kopia pakietu postgresql -> postgresqlX.Y tam ustawiony inny %{_prefix} i tak budowane Najlepiej od razu dodać bconda do speca, żeby budował z innym %{_prefix} (np. /usr/lib/postgresql-old} i pomijał niepotrzebne pliki/podpakiety. Wtedy pozostaje skopiowanie pakietu pod nową nazwą puszczenie budowania z bcondem. Alternatywnie bcond by pakował, zamiast standardowego zestawu pakietów: %package -n postgresql%{version} z plikami serwera w innym katalogu. Wtedy można by to z jednego speca, z brancha na buildery słać. Ale wtedy automatyka FTPowa będzie krzyczeć, że z różnych wersji src.rpm pakiety są. Pozdrowienia, Jacek _______________________________________________ pld-devel-pl mailing list [email protected] http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
