Re: Portability (was Re: [HACKERS] Development installation fails)

Поиск
Список
Период
Сортировка
От Peter Eisentraut
Тема Re: Portability (was Re: [HACKERS] Development installation fails)
Дата
Msg-id Pine.GSO.4.02A.9911301731560.13278-100000@Vessla.DoCS.UU.SE
обсуждение исходный текст
Ответ на Re: Portability (was Re: [HACKERS] Development installation fails)  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Ownership/protection (was Re: [HACKERS] Portability)  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Tue, 30 Nov 1999, Tom Lane wrote:

> No, that part is easy:
> 
> for dir in `echo $PATH | sed 's/:/ /g'` ; do
>   if [ -x $dir/initdb ]; then
>     ...

Cool.

> I think the harder part is manipulating $0 to see if it contains a path
> part or not --- not all systems have dirname, so you need to fake it
> with a sed pattern.  See the configure script for the standard way.
> (BTW, I see the new run_check.sh driver depends on dirname ... boo hiss.)

You see, it just gets worse and worse as you start digging ... :(
No, seriously: *which* system doesn't have dirname? Does it have basename?

> Huh?  The user of your choice *is* postgres, or whoever you are su'd as.
> -o and -g are useless unless you are executing the install as root,
> which really isn't necessary --- in fact I think we ought to discourage
> it to prevent people from accidentally installing the postgres files
> with root ownership.  (initdb ought to refuse to run at all as root...)

There is a very good reason for running the installation process as any
user you choose, because the usual sequence

./configure
make
make install

will fail to create the installation directory (/usr/local/pgsql). That
blows. Then you have to su as root and create it and then go back and
continue. Then you notice you made the directory but forgot to change the
ownership to postgres. Next time you forget that altogether and then all
your files are owned by root. This is exactly what makes the INSTALL so
long. I have always resorted to installing everything as root and then
doing a chown --recursive (talk about non-portable ;) ), that was much
more convenient.

I'm not sure about the terminally convenient and flexible way yet either,
though. But at least we're agreed that all this environment variable stuff
needs to go away.

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



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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] sort on huge table
Следующее
От: Lamar Owen
Дата:
Сообщение: Re: [HACKERS] Re: [ADMIN] When postgres will be faster?