Installation layout

Поиск
Список
Период
Сортировка
От Peter Eisentraut
Тема Installation layout
Дата
Msg-id Pine.LNX.4.21.0006300107220.397-100000@localhost.localdomain
обсуждение исходный текст
Ответы Re: Installation layout  (Bruce Momjian <pgman@candle.pha.pa.us>)
Re: Installation layout  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Installation layout  (Brook Milligan <brook@biology.nmsu.edu>)
Список pgsql-hackers
Here are a few changes to the installation layout for your approval.

The *.sample files and the initdb input files (BKI) should go into
PREFIX/share, not lib. Since only initdb has to know about this there
should be no problems. As for finding these files, the easiest and safest
method would be to substitute this path into initdb at build time.
Override with -L is of course possible. (The "lib" mnemonic would be gone,
think of it as "location".)

At that time, could we rename these bki files to something readable, like

global.bki
global.description
template1.bki
template1.description

It is my understanding that originally the *.bki.source files were
converted to *.bki at some point (forgot where), but we don't do that
anymore. And we don't support more than one set of input files either
(global1.bki, global2.bki?). Again, only initdb needs to know about this.


The odbcinst.ini file has been installed somewhere between PREFIX,
PREFIX/etc, PREFIX/share or just /share or just /etc depending on which
sort of installation procedure you chose or which of these directories
already existed. I suggest we settle on PREFIX/etc. There's still that
--with-odbcinst option for those who prefer differently.


The same for the Kerberos 5 keytab file. Can't be in PREFIX/, ought to be
in PREFIX/etc.


-- 
Peter Eisentraut                  Sernanders väg 10:115
peter_e@gmx.net                   75262 Uppsala
http://yi.org/peter-e/            Sweden



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

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Changes to handling version numbers internally
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: Misc. consequences of backend memory management changes