Submitting ebuilds and patches for dev-db/postgresql and dev-db/libpq version 8.3_rc1. So far I have done limited testing on amd64 only, but it should be ready for masked inclusion.
Created attachment 141341 [details] libpq/libpq-8.3_rc1.ebuild
Created attachment 141343 [details] libpq/files/libpq-8.3_rc1-gentoo.patch
Created attachment 141345 [details] postgresql/postgresql-8.3_rc1.ebuild 1) I dropped the postgresql-8.2.6-regress_fix.patch because I didn't have any problems with the tests without. However, I am not completely sure if it can be dropped or not. 2) I changed the 'sed' line a bit, because my $WORKDIR includes a trailing slash for some reason. So the expected testcase output included the redundant slash, but PostgreSQL itself dropped it, causing a failure.
Created attachment 141347 [details] postgresql/files/postgresql-8.3_rc1-gentoo.patch
Created attachment 141349 [details] postgresql/files/postgresql-8.3_rc1-regress_su.patch
Created attachment 141351 [details] postgresql/files/postgresql-8.3_rc1-sh.patch This patch applies cleanly, but I haven't tested it because I don't have access to such an architecture.
Created attachment 141352 [details] postgresql/files/postgresql.conf-8.3 Dropped the PGOPTS="-N 40 -B 80" line because: 1) Didn't work outright, PostgreSQL 8.3 requires at least 86 buffers; 2) When users see "max_connections = 100" in the configuration file, they actually expect PostgreSQL to handle 100 concurrent connections -- they do *NOT* expect the distro to override essential things like these. This was a huge surprise to me, unexpected things like these only serve to reduce people's confidence in Gentoo.
Created attachment 141354 [details] postgresql/files/postgresql.init-8.3
Also works with postgresql-8.3.0 final release, files just need to be renamed.
I just finished installing 8.3.0 final after throwing the attached files into my overlay and everything seems to work fine. :) Note for others: only rename the files with 8.3_rc1 to 8.3.0; conf and init file must end in -8.3 without the trailing .0
+1 on getting this into the tree. I'd like to roll out PG 8.3 via ports to my machines ASAP.
(In reply to comment #11) > +1 on getting this into the tree. I'd like to roll out PG 8.3 via ports to my > machines ASAP. If you want you can use my Mercurial Portage overlay at http://hg.juffo.org/junkoverlay (run 'hg clone http://hg.juffo.org/junkoverlay' to make a local copy).
(In reply to comment #12) > If you want you can use my Mercurial Portage overlay at > http://hg.juffo.org/junkoverlay > (run 'hg clone http://hg.juffo.org/junkoverlay' to make a local copy). > Your ebuild seems to be missing new feature of postgresql - XML support. I think You should add something like "$(use_with xml libxml)" to postgresql ebuild. Without --with-libxml configure option, XML operations are not supported.
(In reply to comment #13) > Your ebuild seems to be missing new feature of postgresql - XML support. Fixed in the overlay, thanks for pointing out!
when can we expect it to be in the tree? thank you
Good question - I was also wondering this. Would any more testing help in getting it in? ~amd64 here.
I really would like to deploy this stuff on my production servers - can you give any comment on your release plans please? If there is anything I can do to help please let me know
+1. At least in the experimental branch of the PostreSQL overlay, please. ;-)
yeah it was released a month ago... is there a bug keeping it from being ~arch in the tree?
It seems that the problem is lack of maintainers.
8.3.1 released (http://www.postgresql.org/ftp/source/v8.3.1/), but cannot find any announcement
(In reply to comment #21) > 8.3.1 released (http://www.postgresql.org/ftp/source/v8.3.1/), but cannot find > any announcement > http://www.postgresql.org/docs/8.3/static/release-8-3-1.html is this in the overlay? and the reporter/maintainer should change the the summary.
am I allowed to report overlay breakage here? I'm going to anyway. emerge: there are no ebuilds to satisfy "=dev-db/postgresql-8.3*". (dependency required by "virtual/postgresql-server-8.3" [ebuild]) emerge: there are no ebuilds to satisfy "=dev-db/libpq-8.3*". (dependency required by "virtual/postgresql-base-8.3" [ebuild]) I'm trying to get 8.3.x up and running like I have 8.2.x running I installed the experimental and testing overlays
*** Bug 214242 has been marked as a duplicate of this bug. ***
FWIW I bumped the originally attached files to 8.3.1 in my local overlay and both libpq and postgres work fine for me, no changes necessary. Instead of littering this bug with more duplicate attachments anybody is free to clone/download from my personal mercurial repo at http://hoho.dyndns.org/hg/portage/ I am genuinely curious why all this has to be so difficult.
(In reply to comment #25) > FWIW I bumped the originally attached files to 8.3.1 in my local overlay and > both libpq and postgres work fine for me, no changes necessary. Instead of > littering this bug with more duplicate attachments anybody is free to > clone/download from my personal mercurial repo at > http://hoho.dyndns.org/hg/portage/ > I am genuinely curious why all this has to be so difficult. > Your ebuild does use xml2 from contrib. According to the readme of 8.3.1 this is deprecated: ---<-8--8->---- # contrib/xml2 is deprecated and planned for removal in 8.4 (Peter) The new XML support in core PostgreSQL supersedes this module. ---<-8--8->---- Other things to look at: - How about adding "debug" USE flag and $(use_enable debug)? - How about adding "threadsafe" USE flag and $(use_enable threadsafe thread-safety) - Have you considered adding --with-gssapi for kerberos? -> $(use_with kerberos gssapi) - Instead of this: cd "${S}/contrib" emake -j1 LD="$(tc-getLD) $(get_abi_LDFLAGS)" || die "contrib emake failed" I would consider using this: emake -j1 LD="$(tc-getLD) $(get_abi_LDFLAGS)" -C contrib all || die "contrib emake failed" - The same goes for the installation. Instead of: cd "${S}/contrib" emake -j1 DESTDIR="${D}" LIBDIR="${D}/usr/$(get_libdir)" install || die "contrib emake install failed" I would consider using this: emake -j1 DESTDIR="${D}" LIBDIR="${D}/usr/$(get_libdir)" -C contrib install || die "contrib emake install failed" - How about adding "--with-system-tzdata=/usr/share/zoneinfo \"? // Steve
(In reply to comment #26) Steve, thanks for the comments. The ebuild isn't "mine" - I just took the very first one originally attached to this bug. However you are certainly right about the deprecated xml module; I will fix/add your suggestions and then post an update.
I've bumped both of these into portage this morning. Please take a look at 8.3.1 in particular and let me know if we need to make changes to it.
(In reply to comment #26) > - How about adding "threadsafe" USE flag and $(use_enable threadsafe > thread-safety) Thread safety only applies to the client libs from the libpq package and that ebuild has the "threads" USE flag. PG itself is not threaded. > - Have you considered adding --with-gssapi for kerberos? -> $(use_with I know nothing about kerberos (except that it's an auth mechanism) and wouldn't really know what I'm doing..suggestions welcome.
FWIW I just tried to add support for zeroconf (bonjour, avahi) but the build barfs with avahi. Turns out that bonjour and avahi disagree on header names and avahi requires patches that are lined up for 8.4. See this thread: http://archives.postgresql.org/pgsql-patches/2007-11/msg00248.php So no avahi for 8.3.x unless someone is brave enough to whip up those patches.
(In reply to comment #28) > I've bumped both of these into portage this morning. > > Please take a look at 8.3.1 in particular and let me know if we need to make > changes to it. > I have some questions regarding the ebuilds now in Portage: - Is there any reason to use RESTRICT="mirror" in the bumped versions? - Could you add a version dependency to libxml2? >=dev-libs/libxml2-2.6.23 - Could you add to econf: $(use_with kerberos gssapi) \ $(use_with xml libxslt) \
(In reply to comment #28) > I've bumped both of these into portage this morning. > > Please take a look at 8.3.1 in particular and let me know if we need to make > changes to it. > thanks caleb. virtual/postgres-* needs to be bumped to 8.3 too.
Version 8.3.1 works fine here (amd64).
(In reply to comment #31) > (In reply to comment #28) > > I've bumped both of these into portage this morning. > > > > Please take a look at 8.3.1 in particular and let me know if we need to make > > changes to it. > > > > I have some questions regarding the ebuilds now in Portage: > - Is there any reason to use RESTRICT="mirror" in the bumped versions? > - Could you add a version dependency to libxml2? > >=dev-libs/libxml2-2.6.23 > - Could you add to econf: > $(use_with kerberos gssapi) \ > $(use_with xml libxslt) \ > Let me prefix this by saying that I'm still new to the ebuild format, so please correct my mis-interpretations. Why do you want to use libxslt for the xml useflag? I think it should be libxml as it is right now. --with-libxslt is deprecated, as mentioned above. The dependency on xslt can also be removed if the use_with for libxslt is removed. (Right now, the dependency is there, but it's never activated as far as I can see, so either way, something needs to change. :) There is an argument to be made for consistency if old builds used the xml useflag to represent the contrib/xml2 functionality, but it's going away sooner or later, so we might as well get the pain over with (with perhaps a warning message if xml is enabled that it now means something different). I agree with your other suggestions, though, and have a couple to add: * we don't need --enable-depend as it's only useful when you build multiple times out of the same working directory * Since 8.3 is no longer an RC, do we need the MY_PV="${PV/_rc/RC}" line?
I have installed this ebuild on 3 machines so far with great success. I am showing anywhere from 15-800% performance improvements with 8.3 over 8.2 (depending on hardware and fsync=[off|on]) and would love to deploy this to more servers, but I don't feel good about doing so until this is un-hardmasked. Please unmask this ASAP. :)
Please use dev-db/postgresql-server, thanks!
