Installation layout

Started by Peter Eisentrautalmost 26 years ago5 messageshackers
Jump to latest
#1Peter Eisentraut
peter_e@gmx.net

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

#2Bruce Momjian
bruce@momjian.us
In reply to: Peter Eisentraut (#1)
Re: Installation layout

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.

Agreed.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026
#3Tom Lane
tgl@sss.pgh.pa.us
In reply to: Peter Eisentraut (#1)
Re: Installation layout

Here are a few changes to the installation layout for your approval.

Looks fine to me.

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

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

As long as you're renaming, maybe ".bki" should be replaced with
something clearer, like ".init"? I never can remember what bki
stands for anyway...

regards, tom lane

#4Bruce Momjian
bruce@momjian.us
In reply to: Tom Lane (#3)
Re: Installation layout

Here are a few changes to the installation layout for your approval.

Looks fine to me.

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

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

As long as you're renaming, maybe ".bki" should be replaced with
something clearer, like ".init"? I never can remember what bki
stands for anyway...

Must be backend init, but it is a misnomer.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026
#5Brook Milligan
brook@biology.nmsu.edu
In reply to: Peter Eisentraut (#1)
Re: Installation layout

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".)

As a point of reference, the NetBSD pkgsrc package for postgresql
already puts the following in /usr/pkg/share/postgresql:

global1.bki.source
global1.description
local1_template1.bki.source
local1_template1.description

Cheers,
Brook