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
Re: (A) native Windows port |
Список | 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 по дате отправления: