| Summary: | ebuild request: slony (postgresql replication) | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Jacob Smullyan <smulloni> |
| Component: | New packages | Assignee: | PgSQL Bugs <pgsql-bugs> |
| Status: | RESOLVED FIXED | ||
| Severity: | enhancement | CC: | aw, caluml, esigra, jesse |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
slony-1.0.2.ebuild
diff against previously attached slony ebuild Tried to get slony working with pg 8 beta 3 |
||
|
Description
Jacob Smullyan
2004-09-02 14:00:38 UTC
Created attachment 39152 [details]
slony-1.0.2.ebuild
this ebuild contains hard-coded pgsql version.
Thanks, it seems to install fine. Hard-coding a postgresql version works, but isn't as flexible as one might like. Some alternatives: 1. determine the postgresql version from what happens to be installed (provided that it within the range slony supports, which is pretty broad); recompile everything as you have in the ebuild, with the current USE flags. DEPEND would be fairly permissive about postgresql version (7.3 or newer). 2. determine the postgresql version from what happens to be installed, as above; additionally, check to see if the source tree exists and use it if so. 3. ignore the currently installed version and use the ebuild function "best_version" to determine the required postgresql version; dynamically use that function to determine DEPEND. I don't know the preferred api for determining the currently installed version of a package from within an ebuild; one might have to do something a bit nasty. I put down 3. for completeness, but I think it is wrong. 1. or 2. seem better to me (2. is perhaps unnecessary); it would be more flexible for users and easier to maintain (you wouldn't have to deal with the power set of slony and postgresql releases!). What do you think? If option 1. isn't too outre, I'll attempt it. Created attachment 39512 [details, diff]
diff against previously attached slony ebuild
It seems that the function defined in /usr/sbin/ebuild.sh, "best_version", will
return the latest *installed* version, which is what we'd want here. However,
if invoked during the depend phase, it prints a warning to stderr (although it
works). All it does is call portageq.
I attach a diff. However, the fact that best_version produces a warning here
makes me think that someone felt using package introspection during the depend
phase is not nice to do. I don't see a bad effect directly following from its
use in this case, but perhaps I'm missing something.
Ooops -- I see now that the assumptions this ebuild makes about what sources are needed for postgresql are not correct for all postgresql versions. This may be correctable by using a >= postgresql depend. It seems that slony in cvs no longer requires the postgresql source tree! So the problem I was trying to solve will be moot by the next slony release. I therefore suggest that the original slony ebuild, without my diff, be checked in as dev-db/slony. I tried to get it working with 8 beta3. (Warning: I have no experience of writing ebuilds)
I used the patch, otherwise it pulled in a load of deps and wanted to downgrade me to 7.x
Problems I found:
The mirrors don't work
--docdir doesn't exist any more
It needs --with-pgsourcetree=/var/tmp/portage/slony-1.0.2/work/postgresql-8.0.0beta3
but it fails with:
checking for cc_r... gcc
configure: error:
********************
* The sourcetree in /var/tmp/portage/slony-1.0.2/work/postgresql-8.0.0beta3
* does not appear to be built. Please make sure to build
* and install PostgreSQL from sources first.
********************
/usr/lib/portage/bin/ebuild.sh: line 54: --enable-depend: command not found
!!! ERROR: dev-db/slony-1.0.2 failed.
!!! Function src_compile, Line 56, Exitcode 127
!!! (no error message)
!!! If you need support, post the topmost build error, NOT this status message.
I will post my ebuild too.
I would love to see this working so I don't have to compile into /usr/local/*
Created attachment 42776 [details]
Tried to get slony working with pg 8 beta 3
It's not pretty, and it didn't work.
Just visited the slony page and saw that 1.0.5 was out. Wish I'd seen that sooner. Sorry. Is this going anywhere? We would like to start using this , but I prefer to use the portage system for package management, Knowing when new releases are out etc. Any updates on this? I've taken an interest in it, I'm going to work on updating it for 1.0.5, plus any additional bug fixes along the way. I'll post my progress here. Hopefully revive some interest in this and get it submitted into cvs. Ray, I am also interested in this. I have created my own ebuild for 1.0.5 and have it working on 3 machines ok. I am now adding extra files for an init script and some configuration (examples) for actually running the thing. I am interested in seeing what you have and comparing it. Perhaps we can create a forum post for this where we can hammer out exactly the best way of making it work and we can test it thoroughly. More chance then of getting something submitted to portage. :) I've added slony-1.1.0_beta4.ebuild to the portage tree. It's working fine in my environment. But please be careful because it's beta version as it's name. (Sorry about ignoring 1.0.* versions. It's very difficult to handle in portage because it requires postgresql source to compile) |
