net/rsync includes a Python script, installed as sbin/rrsync. It does not, however, declare a dependency on Python; pkg-message advises that Python might be needed. I was just bitten by this when upgrading some systems to Python 3.12 left the script with the old shebang line. This patch adds a port option, PYTHON, that controls whether rrsync is installed and adds the necessary dependency. pkg-message vaguely referred to "some scripts provided by rsync" that require Python, but I'm only aware of the one. I chickened out in PYTHON_DESC anyway. The option is off by default (updating the package will remove rrsync) because removing a script that may not have worked is less intrusive than installing Python that may not have been there.
Created attachment 259521 [details] Patch
I ran into the same problem. It would be nice if this patch (or some variation) would be implemented.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=f02bc3be718072b75bd291f81f66b7f15865f535 commit f02bc3be718072b75bd291f81f66b7f15865f535 Author: Rodrigo Osorio <rodrigo@FreeBSD.org> AuthorDate: 2025-12-28 16:23:04 +0000 Commit: Rodrigo Osorio <rodrigo@FreeBSD.org> CommitDate: 2025-12-28 17:36:56 +0000 net/rsync: Fix stealth dependency on Python net/rsync includes a Python script installed as sbin/rrsync without declaring a dependency on Python. Adds a port option, PYTHON, that controls whether rrsync is installed and adds the necessary dependency and remove the pkg-message who advises that Python might be needed. By default this option is off (updating the package will remove rrsync). PR: 286073 Reported by: Christian Ullrich <chris@chrullrich.net> UPDATING | 9 +++++++++ net/rsync/Makefile | 20 ++++++++++++++------ net/rsync/pkg-message (gone) | 8 -------- net/rsync/pkg-plist | 4 ++-- 4 files changed, 25 insertions(+), 16 deletions(-)
Committed with minor changes, thanks
FWIW, I just got bitten by the removal of rrsync from the default build.
I feel this change breaks POLA. All users who use rrsync can no longer use the default build. They have to create their own package.
(In reply to Dan Langille from comment #6) That is a problem. Sorry for not considering that; I'm not used to thinking about upstream binary packages. On the other hand, I still think requiring Python on the off chance that someone uses rrsync is quite astonishing itself, and I don't like installing a script that cannot be run. I can think of two possible fixes short of reverting the patch: - Always install rrsync into DATADIR (or by any other name). - Make the Python dependency a flavor. AIUI the package cluster builds all flavors (?).
(In reply to Christian Ullrich from comment #7) Requiring Python might be astonishing, however it was in place for some time (years I think). I started typing this: Is this acceptable? * always install rrsync * change the PYTHON default to ON for now * include a notice in pkg-message saying the PYTHON default will be changing to off "soon" In short, install the script, let the user decide to install Python if they need the script. Then thought about flavors: one with python, one without. I'm still not clear in my head yet.
(In reply to Dan Langille from comment #8) > Requiring Python might be astonishing, however it was in place for > some time (years I think). It was not. net/rsync did not have a dependency on Python under any circumstances but installed rrsync anyway. > I started typing this: > > Is this acceptable? > > * always install rrsync > * change the PYTHON default to ON for now > * include a notice in pkg-message saying the PYTHON default will be > changing to off "soon" > > In short, install the script, let the user decide to install Python if > they need the script. That is mostly what I meant by installing rrsync into DATADIR, just so the package does not install something into /usr/local/sbin that actually cannot run. In this case I would rather drop the Python dependency entirely again. If the user decides to pull the script out of /usr/local/share/rsync or wherever, or run it from there, then whether or not it works is up to them. My original motivation for this patch was that, without such a dependency, changing the Python version would just leave the rsync package installed and therefore not update rrsync's shebang line. > Then thought about flavors: one with python, one without. This is the better solution, but I have never made a flavored port yet. This will take some time.
Some time has passed. What do you think about <https://github.com/chrullrich/freebsd-ports-public/tree/net-rsync-python>? This is main plus one commit. It is only a Python-or-no-Python selection. It does not bring in the whole slew of possible Python flavors and therefore will select the PYTHON_DEFAULT only. I think.
(In reply to Christian Ullrich from comment #9) >It was not. net/rsync did not have a dependency on Python under any circumstances but installed rrsync anyway. Oh, I misunderstood what was being said. Sorry. In my case, I always have Python installed. As for `/usr/local/bin/python3.11` I say the SHEBANG is doing the wrong thing. I think it should be `#!/usr/bin/env python`, for example. I admit, my knowledge in this area is greatly lacking. > This is the better solution, but I have never made a flavored port yet. This will take some time. I am happy to assist you with that.
This removal of rrsync bit me as well. I use it to set a different SSH identity when using automated rsync to backup files to a remote server (e.g., "-e ssh -i ~/.ssh/identity"). Removing rrsync breaks this functionality.
Reopen this PR
Created attachment 267381 [details] Patch Replaces the PYTHON option with a python flavor. Feedback is welcome, particularly on whether it should support non-default Python versions (@py3xx flavors).
(In reply to Christian Ullrich from comment #14) I will test this at home and let you know.
(In reply to Dan Langille from comment #15) FYI: Patching file net/rsync/Makefile using Plan A... Hunk #1 succeeded at 1. Hunk #2 succeeded at 19. Hunk #3 succeeded at 57 with fuzz 2. Hunk #4 succeeded at 66 (offset -1 lines). Hunk #5 failed at 82. Hunk #6 succeeded at 118 (offset -2 lines). 1 out of 6 hunks failed--saving rejects to net/rsync/Makefile.rej done [16:28 pkg01 dvl /usr/local/poudriere/ports/default] % sudo cat net/rsync/Makefile.rej @@ -70,12 +82,8 @@ POPT_PORT_LIB_DEPENDS= libpopt.so:devel/popt POPT_PORT_CONFIGURE_OFF= --with-included-popt -PYTHON_USES= python:run shebangfix - RENAMED_EXTRA_PATCHES= ${WRKSRC}/patches/detect-renamed.diff -PYTHON_USES= python:run shebangfix - SSH_CONFIGURE_ON= --with-rsh=ssh SSH_CONFIGURE_OFF= --with-rsh=rsh [16:29 pkg01 dvl /usr/local/poudriere/ports/default] % I'll amend the file manually.
(In reply to Dan Langille from comment #16) I see now, the patch is merely a duplicate at the end... Looks good to me. The patch does the expected thing for me here. This: % sudo poudriere testport -j 143amd64 -p default -z primary -i net/rsync Gives this: nobody@143amd64-default-primary:/usr/ports/net/rsync $ pkg info -l rsync | grep rrsync nobody@143amd64-default-primary:/usr/ports/net/rsync $ That is: no rrsync installed. This: sudo poudriere testport -j 143amd64 -p default -z primary -i net/rsync@python Gives this: nobody@143amd64-default-primary:/usr/ports/net/rsync $ pkg info -l rsync-python | grep rrsync /usr/local/sbin/rrsync /usr/local/share/doc/rsync/rrsync.1.md nobody@143amd64-default-primary:/usr/ports/net/rsync $ pkg info -x python python312-3.12.12_3 rsync-python-3.4.1_6
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=fc42790ae011acedf0195c7d31b1cf63b8c02155 commit fc42790ae011acedf0195c7d31b1cf63b8c02155 Author: Christian Ullrich <chris@chrullrich.net> AuthorDate: 2026-01-22 16:55:08 +0000 Commit: Dan Langille <dvl@FreeBSD.org> CommitDate: 2026-01-22 16:57:09 +0000 net/rsync: Reinstate rrsync by flavorizing The previous update removed the rrsync script from binary packages built with the default options. This replaces the PYTHON option with a python flavor so there is a package available that contains rrsync. PR: 286073 Reported by: Dan Langille <dvl@freebsd.org> net/rsync/Makefile | 24 +++++++++++++++++------- 1 file changed, 17 insertions(+), 7 deletions(-)
Committed. Thank you for that patch. I'm leaving the PR open for at least a bit longer.
Hi Dan, If the fix looks good, I didn't appreciate that much a commit on against my will. Regards, -- rodrigo
(In reply to Rodrigo Osorio from comment #20) Rodrigo, I apologize. I should absolutely have waited for maintainer feedback. Sorry.
Dan, Thanks for your your apology, no big harm. I think we can mark this PR as fixed for now. Regards, -- rodrigo
Thank you.
An idea: All ports which now include net/rsync now need to consider/provide net/rsync@python What if we used flavors to create two non-conflicting ports? With that goal in mind, what if net/rsync@python installed only the python scripts? Then it would not conflict with net/rsync and could be installed side-by-side? This idea came to me while composing https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=293599
(In reply to Dan Langille from comment #24) Honestly, if I had known what an epic tale this would become, I'd have never opened the bug in the first place :-). I don't think having one flavor that can rsync, but cannot be restricted, and another that can restrict rsync, but doesn't install it, is a viable idea. I'd rather just split rrsync out into a separate port. OTOH, creating an entire port to install a 300-LOC script is ridiculous. Let's just stuff it back into net/rsync, drop the entire Python machinery, and return the port to what it was before I started having clever ideas. If the user _has_ to manually install another port to get a working rrsync, it might as well be Python.
(In reply to Dan Langille from comment #24) Hi Dan, You mean having something like a net/rsync-rrsync package who provides the rrsync script and requires net/rsync + python. This is a great idea, and solves the issue you point at, when you have 2 packages package A who requires net/rsync@python package B who requires net/rsync@default and installing A then B cause conflicts. Since there is no rush I suggest to implement the feature and start testing it to see if there is no drawbacks. This will avoid more back and forth on this port :p .
(In reply to Rodrigo Osorio from comment #26) I am tempted to go the route mentioned by Christian in #25 - revert the port to what it was before we flavored. There are many ports which use net/rsync and having them make flavor changes too... seems demanding.
(In reply to Dan Langille from comment #27) I plan to proceed with that change this weekend. Sorry for the past and upcoming churn.
(In reply to Rodrigo Osorio from comment #26) I'm sorry, you're the maintainer. I'm holding. I haven't heard from you since I mentioned my preference to revert rsync to what was in place with 3.4.1_4 - that seems to be the simple solution. It appears few people use rrsync and most were happy installing python when required.
(In reply to Dan Langille from comment #29) Sorry I was a little bit overbooked, but now I have time to revert the changes done in fc42790ae011acedf0195c7d31b1cf63b8c02155.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=b350a4db575c9bea83ec5d7028066aa7bf91a9bb commit b350a4db575c9bea83ec5d7028066aa7bf91a9bb Author: Rodrigo Osorio <rodrigo@FreeBSD.org> AuthorDate: 2026-04-18 17:24:56 +0000 Commit: Rodrigo Osorio <rodrigo@FreeBSD.org> CommitDate: 2026-04-18 20:18:39 +0000 net/rsync: revert to single package without Python dependency Restore the previous setup with a single net/rsync package that includes the rrsync script but does not depend on Python. Users who require the rrsync script must install Python separately, as indicated in the install message. Bump PORTREVISION This reverts commit fc42790ae011acedf0195c7d31b1cf63b8c02155. This reverts commit f02bc3be718072b75bd291f81f66b7f15865f535. PR: 286073 UPDATING | 11 +++++++++++ net/rsync/Makefile | 28 +++++----------------------- net/rsync/pkg-message (new) | 8 ++++++++ net/rsync/pkg-plist | 4 ++-- 4 files changed, 26 insertions(+), 25 deletions(-)
I think we are done with this PR, thanks ;)
A commit in branch 2026Q2 references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=d1bc05a40b7069392ca417e5dcad0d2aaafe3308 commit d1bc05a40b7069392ca417e5dcad0d2aaafe3308 Author: Rodrigo Osorio <rodrigo@FreeBSD.org> AuthorDate: 2026-04-18 17:24:56 +0000 Commit: Rodrigo Osorio <rodrigo@FreeBSD.org> CommitDate: 2026-05-21 09:26:33 +0000 net/rsync: revert to single package without Python dependency Restore the previous setup with a single net/rsync package that includes the rrsync script but does not depend on Python. Users who require the rrsync script must install Python separately, as indicated in the install message. Bump PORTREVISION This reverts commit fc42790ae011acedf0195c7d31b1cf63b8c02155. This reverts commit f02bc3be718072b75bd291f81f66b7f15865f535. PR: 286073 (cherry picked from commit b350a4db575c9bea83ec5d7028066aa7bf91a9bb) UPDATING | 11 +++++++++++ net/rsync/Makefile | 28 +++++----------------------- net/rsync/pkg-message (new) | 8 ++++++++ net/rsync/pkg-plist | 4 ++-- 4 files changed, 26 insertions(+), 25 deletions(-)