So after the rsync update that got pulled in today I got to wondering why I needed rsync after all, given all my repos including gentoo are set to git sync and I'm not using rsync locally ATM, tho I have in the past. Turns out the only thing pulling in rsync is portage (I've been running a null @system for years, if it'd otherwise be pulled in that way instead of just as a portage dep), and for portage it's a PDEPEND. So for portage's benefit I setup a null-package rsync ebuild in my overlay and merged it, replacing the real rsync. While I've obviously not tested for long yet, I don't /believe/ rsync's used to pull sources or anything, so I should be good to go. Of course that implies that instead of hard-coding portage's rsync PDEPEND, it should be made an on-by-default USE=rsync and IUSE=+rsync based PDEPEND, thus this enhancement request bug. =:^) (If there's already an open request for this my bugzi google-foo was insufficient to find it...)
We also use rsync as part of the FEATURES=install-sources implementation, so we'll have to add a note about that in the USE=rsync documentation.
An additional note on running rsync-less, since it appears someone else is interested enough to CC, now. Building something else, from memory either linux-headers or the kernel itself (which I build independent of portage), required rsync, so I ended up remerging the real rsync package. In theory I could have found what was calling rsync and patched that call to a cp or some such, but it was easier to just remerge the real rsync package. If this request-bug ever gets fixed and depclean wants to remove rsync as a result, I'll deal with it then (unless something else, say an rsync update build bug, triggers another look before that).
I did a quick search (at least in ::gentoo) to verify rsync is not being called directly within any ebuilds and eclasses... Only thing I found of value was the following line from the sci-biology/profphd/files/profphd-1.0.40-symlink.patch file: mkdir -p $(DESTDIR)$(prefix)/share/profphd/prof/embl/para && rsync -aC \ Which seems to be a Makefile calling rsync after creating a directory (at package install time). Question what packages depend / call rsync without documenting it? Like you said, the best way to tell would be to remove rsync and see how usable the system is (at least test packages in the @system set for the various profiles).
