Created attachment 206178 [details] SVN patch Hi, Here is port of pg_probackup, yet another PostgreSQL backup tool which provides incremental backups. It's quite good alternative to pg barman. It works fine at least for me. Thanks!
(1) I'm getting a build failure: ``` src/utils/thread.o src/utils/remote.o src/utils/file.o src/archive.o src/backup.o src/catalog.o src/checkdb.o src/configure.o src/data.o src/delete.o src/dir.o src/fetch.o src/help.o src/init.o src/merge.o src/parsexlog.o src/pg_probackup.o src/restore.o src/show.o src/util.o src/validate.o src/pg_crc.o src/datapagemap.o src/receivelog.o src/streamutil.o src/xlogreader.o src/walmethods.o -L/usr/local/lib -lpgcommon -lpgport -L/usr/local/lib -lpq -D_THREAD_SAFE -D_REENTRANT -D_THREAD_SAFE -D_POSIX_PTHREAD_SEMANTICS -L/usr/local/lib -L/usr/local/lib -lpthread -L/usr/local/lib -fstack-protector-strong -L/usr/local/lib -Wl,--as-needed -Wl,-R'/usr/local/lib' -lpgcommon -lpgport -lintl -lssl -lcrypto -lz -lreadline -lcrypt -lm -o pg_probackup /usr/bin/ld: error: unable to find library -lpgcommon /usr/bin/ld: error: unable to find library -lpgcommon cc: error: linker command failed with exit code 1 (use -v to see invocation) gmake[1]: *** [/usr/local/lib/postgresql/pgxs/src/makefiles/pgxs.mk:430: pg_probackup] Error 1 gmake[1]: Leaving directory '/wrkdirs/usr/ports/databases/pg_probackup/work/pg_probackup-2.1.5' ===> Compilation failed unexpectedly. Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to the maintainer. *** Error code 1 ``` libpgcommon.a is installed by postgresql11-server-11.4_1, so you'll need to add: WANT_PGSQL= lib server Ideally, you'ld only need postgresql-server installed as a build dependency, but it seems Mk/Uses/pgsql.mk doesn't have any provision to do that. (2) pg_probackup states that it is compatible with postgresql 9.5, 9.6, 10, 11 and it would be good to support all of those, rather than limiting to just 11. The tricky part there seems to be extracting the DISTVERSION for the appropriate postgresql-server port. It would also mean eliminating your use of the PG_VERSION variable -- something that portlint flags as an error. There is a fairly obscure mechanism in the ports where you can depend on the checked-out WRKDIR of a different port. I need to dig a bit to remind myself exactly how that works and if it would be suitable for this use case.
Thank you, Matthew! (1) Oh, my fault. I'll testport it better via poudriere. (2) I wonder if flavors can solve such kind of issue, i.e. there will be one port and several packages targeted to different versions of PG. I never tried flavors, so I'm newbie to them. Is it worth to flavor-ize this port? Best regards.
(In reply to Michael Zhilin from comment #2) Yes, ideally flavours are the preferred current approach to dealing with multiple variants of a port's dependencies. However, in the case of postgresql we don't currently have any setup in the ports to support different postgresql flavours. Adding postgresql flavouring would be a rather large project... Instead there are two options: 1) Slave ports to support different versions of postgresql 2) Just having one port, but making it adapt to the version of postgresql set in DEFAULT_VERSIONS In general you'ld get (2) pretty much automatically from the 'USES+= pgsql' mechanism, except in this case you need access to the source code of postgresqlXX-server in order to build the software. Hmmm... about the cleanest and simplest way I can see to handle this is to have an OPTIONS setting allowing the user to choose which upstream postgresql version to use. You're still going to have to manually update the exact postgresql version whenever postgresql updates, or else the port will break.
Walter Schwarzenfeld, Is there any naming convention for port tickets? Thanks!
(In reply to Michael Zhilin from comment #4) New port should appear on the begin of the line.