Re: (A) native Windows port

Поиск
Список
Период
Сортировка
От Oliver Elphick
Тема Re: (A) native Windows port
Дата
Msg-id 1026229787.1183.70.camel@linda
обсуждение исходный текст
Ответ на Re: (A) native Windows port  (Bruce Momjian <pgman@candle.pha.pa.us>)
Ответы Re: (A) native Windows port  (Hannu Krosing <hannu@tm.ee>)
Re: (A) native Windows port  (Peter Eisentraut <peter_e@gmx.net>)
Список pgsql-hackers
On Tue, 2002-07-09 at 16:41, Hannu Krosing wrote:
> On Tue, 2002-07-09 at 13:48, Oliver Elphick wrote:
> > On Tue, 2002-07-09 at 01:30, Matthew T. O'Connor wrote:
> > > Example: When PG 7.3 is released, the RPM / deb / setup.exe include the 
> > > postmaster binary for v 7.2 (perhaps two or three older versions...). 
> > 
> > That isn't usable for Debian.  A package must be buildable from source;
> > so I would have to include separate (though possibly cut-down) source
> > for n previous packages.  It's a horrid prospect and a dreadful kludge
> > of a solution - a maintainer's nightmare.
> 
> The old postmaster should not be built/distributed. As it is for
> _upgrading_ only, you just have to _keep_ it when doing an upgrade, not
> build a new "old" one ;)

No, it doesn't work like that.  You cannot rely on anything's being left
from an old distribution; apt is quite likely to delete it altogether
before installing the new version (to enable dependencies to be
satisfied).  At present I have the preremoval script copy the old
binaries to a special location in case they will be needed, but that
fails if the version is very old (and doesn't contain that code), and
it's a very fragile mechanism.

I never have understood why the basic table structure changes so much
that it can't be read; just what is involved in getting the ability to
read old versions?




В списке pgsql-hackers по дате отправления:

Предыдущее
От: Thomas Lockhart
Дата:
Сообщение: Re: Units for storage of internal time zone offsets
Следующее
От: Hannu Krosing
Дата:
Сообщение: Re: (A) native Windows port