Bug 210228

Summary: sysutils/duplicity: Depends on net/librsync but should depend on net/librsync1
Product: Ports & Packages Reporter: Niklaas Baudet von Gersdorff <me>
Component: Individual Port(s)Assignee: Jase Thew <jase>
Status: Closed FIXED    
Severity: Affects Only Me CC: bdrewery, jase, w.schwarzenfeld
Priority: --- Keywords: needs-qa
Version: LatestFlags: vlad-fbsd: maintainer-feedback? (jase)
Hardware: Any   
OS: Any   
Bug Depends on: 210073    
Bug Blocks:    
Attachments:
Description Flags
testport log of proposed diff none

Description Niklaas Baudet von Gersdorff 2016-06-12 10:22:35 UTC
I came across this because I tried to install sysutils/duplicity and net/csync2 on the same machine. Duplicity depends on net/librsync while csync2 depdends on net/librsync1. Because librsync and librsync1 are in conflict I can only install one while removing the other.

I checked http://duplicity.nongnu.org/README where it says that duplicity requires "librsync v0.9.6 or later" so changing the runtime dependency to net/librsync1 should be fine. I have not tested this yet though.

Anyway, I don't know how to exactly handle this since net/librsync seems unmaintained, so maybe it would make sense to substitute net/librsync with net/librsync1, that is renaming net/librsync1 to net/librsync and abandoning the old version. But probably this would cause even greater dependency problems.
Comment 1 Niklaas Baudet von Gersdorff 2016-06-12 10:33:02 UTC
I just checked, only the following depend on net/librsync:

sysutils/duplicity
sysutils/rdiff-backup-devel

However, these three depend on net/librsync1:

net/csync2
sysutils/burp
sysutils/rdiff-backup
Comment 2 Walter Schwarzenfeld 2016-06-12 12:15:41 UTC
There is an update PR https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210073.
I have the updated version installed and it has librsync.so.1.
Comment 3 Walter Schwarzenfeld 2016-06-12 12:21:09 UTC
Please, try this updated version. On my system it is the only port  uses librsync. Maybe, you deinstall librsynce und pull it new in with duplicity. If it is so, I will change the Makefile in the update PR to librsync.so.1. Please tell me.
Comment 4 Walter Schwarzenfeld 2016-06-12 12:27:39 UTC
Sorry, I was not really clear. If you deinstall librsync, you have recompile all other ports that used that library.
If this causes no problems, I hat to change nothing. If they use the old version,  I have to change it.
Comment 5 VK 2016-06-12 14:59:55 UTC
Adjusting summary to de-confuse Bugzilla, requesting proper maintainer feedback.

w.schwarzenfeld, the way I understood the problem, it should be librsync.so.2 which is installed by net/librsync1.
Comment 6 Niklaas Baudet von Gersdorff 2016-06-12 15:34:59 UTC
Sorry, in case I was not clear enough. Please see the following:

---
$ pkg info | grep duplicity
duplicity-0.7.06               Backup tool that uses librsync and GnuPG
duply-1.10.1                   Shell front end for the duplicity backup tool

$ sudo pkg install csync2
Password:
Updating FreeBSD repository catalogue...
FreeBSD repository is up-to-date.
Updating niklaas.eu-default repository catalogue...
niklaas.eu-default repository is up-to-date.
Updating niklaas.eu-py35 repository catalogue...
niklaas.eu-py35 repository is up-to-date.
All repositories are up-to-date.
Checking integrity... done (1 conflicting)
Checking integrity... done (0 conflicting)
The following 5 package(s) will be affected (of 0 checked):
 
Installed packages to be REMOVED:
        librsync-0.9.7_3
        duplicity-0.7.06
        duply-1.10.1
 
New packages to be INSTALLED:
        csync2: 2.0_1 [FreeBSD]
        librsync1: 1.0.0 [FreeBSD]
 
The operation will free 2 MiB.
 
Proceed with this action? [y/N]:
---

I assume this is because librsync and librsync1 cannot be installed together. Please correct me if I am wrong.

If there is no particular reason why there are two ports for librsync (one for version 0.9.7_3 and one fore 1.0.0), I propose to either re-write ports depending on net/librsync to depend on net/librsync1 and abandon net/librsync or abandon current net/librsync and rename net/librsync1 to net/librsync.

I just did the following to sysutils/duplicity:

---
diff -ru old/Makefile new/Makefile
--- old/Makefile        2016-06-12 13:15:54.275756000 +0200
+++ new/Makefile        2016-06-12 14:16:18.941175000 +0200
@@ -9,7 +9,7 @@
 MAINTAINER=    jase@FreeBSD.org
 COMMENT=       Backup tool that uses librsync and GnuPG
 
-LIB_DEPENDS=   librsync.so:net/librsync
+LIB_DEPENDS=   librsync.so:net/librsync1
 RUN_DEPENDS=   ${PYTHON_PKGNAMEPREFIX}lockfile>=0:devel/py-lockfile
 
 USES=          python:2
@@ -91,6 +91,7 @@
 .endif
 
 post-install:
+       ${STRIP_CMD} ${STAGEDIR}${PREFIX}/lib/python2.7/site-packages/duplicity/_librsync.so
        ${MKDIR} ${STAGEDIR}${DOCSDIR}
 .for f in ${PORTDOCS}
        ${INSTALL_DATA} ${WRKSRC}/${f} ${STAGEDIR}${DOCSDIR}
---

After creating and installing the packge, I could install csync2 without any problems. In addition, I just tested creating a backup with duplicity as compiled above and it worked just fine.
Comment 7 Walter Schwarzenfeld 2016-06-12 16:02:08 UTC
OK, I have misunderstood.
But there is something no clear:
If librsync.so.1 is install, the reinstallation of duplicity ignores libsync.so:net/libsync1. After deinstalled it per hand,
it installs librsync.so.2.
Freshport lists four ports  uses librsync:
devel/codeblocks, sysutils/rdiff  sysutils/rdiff-devel and sysutils/duplicity.

Devel/codeblocks seems  don't need librsync.

sysutils/rdiff has in the Makefile
LIB_DEPENDS=  librsync.so:net/librsync1
sysutils/rdiff-devel
LIBS_DEPENS=  librsync.so:net/librsync

so I guess the second one is wrong.

And if it is so, we don't need librsync anymore only librsync1.

(I have "grepped" the Makefiles in the ports-tree and find one more port has librsync, but it has librsync1 - sysutils/burp).
Comment 8 Walter Schwarzenfeld 2016-06-12 16:16:57 UTC
Changed patch in the  update PR.
Comment 9 Niklaas Baudet von Gersdorff 2016-06-12 16:34:04 UTC
Created attachment 171341 [details]
testport log of proposed diff

Since it seems you took the diff of Comment 6, this is the relevant testport log.

stage-qa failed before I added ${STRIP_CMD} that's why I added it.
Comment 10 Niklaas Baudet von Gersdorff 2016-06-21 08:44:58 UTC
Probably this can be closed because bug 210073 was closed, w.schwarzenfeld?
Comment 11 Walter Schwarzenfeld 2016-06-21 10:12:37 UTC
Please, close it.
Comment 12 Niklaas Baudet von Gersdorff 2016-06-21 10:34:20 UTC
Closed.

(You should be able to close reports too, w.schwarzenfeld.)