Danek, sorry for the late reply: I've been busy with my day job lately ;-)
> > * As I had already commented two months ago in the only message on the > > solarispackages-hackers at pgfoundry.org mailing list > > > > > > http://lists.pgfoundry.org/pipermail/solarispackages-hackers/2006-March/000000.html > > > > I have some issues with the directories selected for some pgsql > > components. To cite from that message: > > > > * Shipping many internal PostgreSQL modules directly in /usr/lib > > completely > > clutters this directory, which should be a no-no. I think only the > > libraries that represent an interface belong there. The modules rather > > belong into /usr/lib/pgsql, just like /usr/lib/dns. > > Similarly with the host of commands that got put into /usr/bin. This was > considered for a long time and with much gnashing of teeth, and the ARC > case was nearly rejected because of it, but was given a one-time exemption > to ship "dirty", with the expectation that it will be fixed the next time > postgres is revved. The team integrating postgres asserted that there was > too much work to do to make this change in the amount of time they had, and > that they already had initial positive feedback from the postgres community > that such a change would be welcome, and preferred to push the change that > way. We'll have to see how that plays out. I'm quite astonished to hear that: I recalled that automake supports pkglibdir (i.e. a package-specific subdir of libdir) for the purpose of storing e.g. package-specific modules that don't belong into libdir directly. When I checked the postgresql sources, I found that automake was not in use, but pkglibdir was accounted for nonetheless, so the only necessary code change was a one-liner in config.patch, as can be seen in the webrev at http://www.techfak.uni-bielefeld.de/~ro/opensolaris/webrev/pg-dirs/webrev/ That change took me under 15 minutes. Right now, there's no --with-pkglibdir or similar configure switch, but that could be easily added since patching src/Makefile.global.in is obviously not the proper approach. > > * The use of /var/lib/pgsql for the the data and backups directories > > seems wrong on Solaris: I can see no reason at all for having > > /var/lib; this seems to be an unfortunate Linuxism that shouldn't > > creep into the Solaris version. I think simply /var/pgsql would be > > more appropriate here. > > > > /var/pgsql would also be much more in line with /var/mysql. > > Probably. The ARC missed that detail with all the rest of the hoopla going > on. That change is even simpler to effect than the previous one, as can be seen in the webrev, too: just change --localstatedir and --sharedstatedir. Apart from the changes proper, there are a couple of packaging changes necesssary to reflect them, but they are simply search-and-replace. With those changes, I was able to successfully build both postgres and the relevant packages. > > * I noticed that currently, pgsql is statically linked against > > libreadline. It would probably be very useful to provide a dynamic > > libreadline, since several other programs could benefit as well, > > e.g. gdb. > > This was a specific decision by the ARC, fearing the introduction of an > attractive nuisance. Readline's license is GPL, hence it "infects" > anything linking against it. This doesn't affect postgres, but would > affect any project that thought they were able to link against readline. > The ARC felt the reward of allowing a shared readline was not sufficient to > balance the risk of projects using it inappropriately. > > The decision can always be revisited on its own. True. There was some talk about this on opensolaris-tools etc. during the discussion on the /usr/gnu proposal. > > * Last but not least, it would be very desirable to have at the very least > > an init.d script for pgsql, but perferably convert it to an SMF service. > > There's an open CR for this, too: > > > > 6405382 No manifest/start method included in SUNWpostgr-server > > > > but I have no idea who the submitter is and how far this has progressed. > > SMF integration was considered by the ARC, and ultimately rejected as a > requirement. The ARC did avise the project team that this should be done, > and that it would be a requirement at the next review. The ARC explicitly > disallowed an init script, as that practice is now strongly discouraged for > Sun projects (just a touch more so, the ARC believed, than SMF is > encouraged). Ok, makes sense (and is in line with how e.g. mysql is handled right now). I see that there's a postgresql SMF manifest at http://blog.sun.com/roller/page/chrisg/?anchor=my_first_smf_service but that has a couple of issues I plan to address since I'm currently in the process of setting up a local zone with postgres 8.1.3. This zone is running my self-compiled postgres packages above, so they seem to be ok. To be honest, though, I've just checked with pmap/pldd that none of the modules in /usr/lib/pgsql are currently loaded. I'll have to try if this really works (or if they are completely irrelevant since most of this is contrib code and not actually used). Apart from that, the webrev above also implements > * Two other issues that might be interesting are > > 6412876 RFE: PostgresQL should support Kerberos authentication > > I'll try this as well, but currently this relies on the exposure of the > krb5 API in snv_38, so it cannot easily backported to S10 until that fix > gets there, too. This took just two changes to Makefile.sfw to enable --with-krb5 and add the header directory returned by krb5-config --cflags to --with-includes. When I tried building postgresql with --with-krb5, the compilation initially failed since one configure test is currently broken: checking for library containing krb5_encrypt... no configure: error: could not find function 'krb5_encrypt' required for Kerberos 5 *** Error code 1 While this function doesn't exist in libkrb5.so.1 (or rather mech_krb5.so.1), this doesn't matter since the function isn't used anywhere in the code. I've removed that check from configure/configure.in, which is currently included in config.patch in the webrev. To do this probably, this should be moved to its own krb5.patch file and the configure bug reported upstream. This change should of course be split off into its own webrev, but I just want to get this out now. I've successfully run the resulting postmaster both with pam and krb5 authentication over an ssl-encrypted connection, but there are strange failures if you don't have a kerberos ticket. This may well be a problem with bitrot in the upstream krb5 code, and is probably best investigated/addressed in the postgresql community. Since libkrb5 won't exist in Solaris 10 before Update 3, there's probably enough time to have those isses fixed before that time. Rainer ----------------------------------------------------------------------------- Rainer Orth, Faculty of Technology, Bielefeld University
