Nils Goroll napsal(a):
> Hi Zdenek,
>
>>> === SYSCONFDIR ===
>>>
>>> (diff from Makefile.global)
>>>
>>> -sysconfdir := /usr/postgres/8.3/etc
>>> +sysconfdir := /etc/pgsql/8.3
>>>
>>> I don't think any config directory should be under /usr (will break
>>> with diskless clients for instance, see filesystem(5)), so I changed
>>> the path and introduced the new package SUNWpostgr-83-client-root,
>>> containing only the sample pgsql rc-file.
>>>
>>> I could come up with arguments for calling the directory both
>>> /etc/postgres and /etc/pgsql. pgsql is what postgres.org calls it,
>>> postgres is the name of the package. IMHO, we should stick to the
>>> names the original authors have chosen, so I think pgsql is better,
>>> but please let me know what you think.
>>
>> No, please. /usr/postgres/8.3/etc contains only example configuration
>> and it is read only. I don't see any benefit to move the directory
>> into /etc. And it is not so easy introduce new package and new
>> directory... (see ARC processes)
>
> Unfortunately, this is not just a sample configuration directory, but
> the compiled in default path. For me, the question is if we want that to
> be incompatible with filesystem layout policies.
If it breaks filesystem layout it should be fixed. What I'm not still
sure if it is really breaks this rule. I'm going to discuss it with PG
community members. Stay tuned
> If the prime directive was not to correct things just to avoid the ARC
> process, then Sun should really question if the ARC process is the best
> thing to do.
No, I only mentioned that new package probably requires to go through ARC.
> To be constructive: If we agree that this should be corrected and if the
> change has has to go through ARC, then it has to go through ARC. Fine.
>
>>> (diff from Makefile.global)
>>>
>>> CC = /opt/SunStudioExpress/bin/cc -Xa
>>> GCC =
>>> -CFLAGS = -xc99=none -xCC
>>> +CFLAGS = -xO3 -xarch=386 -xchip=pentium -xspace -Xa -xildoff
>>> -xc99=all -xc99=none -xCC
>>>
>>> In the oritinal Makefile.sfw, the default cflags were used everywhere
>>> (also for the 64bit version), BUT for the target $(VER)/config.status
>>>
>>> Thus it does look like an error that the (sensible) default CFLAGS are
>>> not used, but I might not be aware of a good reason for choosing the
>>> minimal CFLAGS.
>>
>> It look likes a bug since 8.1 integration. Fortunately, compiler
>> setting seems ok. Check pg_config before and after your changes. They
>> should not be different.
>
> CFLAGS returned by pg_config are the same, so this should be OK then?
Yes. It is OK.
>> METADATA
>> - version 8.3.4 is already in SFWNV (build 100)
>
> Downloading sfw-src-b100-20080930.tar.bz2 now... (alwyas behind when
> you're outside SWAN :-( )
We are going to move on mercurial soon. It should be better.
>
>> - PROGRAM name is PostgreSQL not postgres
>
> Agree (see a similar comment in my original post), but PROGRAM is used
> to generate VER and if we wanted to make it PostgreSQL, we'd need to
> change a whole lot of directory names:
>
> haggis:~/Devel/sfw-src-b99-20080918.symlink/usr/src/cmd/postgres/postgresql-8.3$
>
> grep PROGRAM ../../../Makefile.master
> COMPONENT_NAME= $(METAINFO) -key PROGRAM
> haggis:~/Devel/sfw-src-b99-20080918.symlink/usr/src/cmd/postgres/postgresql-8.3$
>
> grep COMPONENT_NAME Makefile.sfw
> VER= $(COMPONENT_NAME:sh)-$(COMPONENT_VERSION:sh)
>
<snip>
>> - mv tmp/post*$(PGMINVER) $(VER64); rm -rf tmp
>> I prefer mv tmp/$(VER) $(VER64); rm -rf tmp
>> (same for 32bit version)
>
> The path in the tar file is postgresql-X.X.X, but $(VER) is postgres-8.3.3
>
> Same as above, I have not made this up and would be happy with a more
> consistent naming, but should we really change this?
I'm little bit confused. Why ${VER} cannot be postgresql-X.X.X?
Directory can stay called postgres.
Zdenek
