Summary: | sys-apps/portage request: make portage's rsync PDEPEND an (on-by-default) USE=rsync IUSE=+rsync PDEPEND | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Duncan <1i5t5.duncan> |
Component: | Current packages | Assignee: | Portage team <dev-portage> |
Status: | CONFIRMED --- | ||
Severity: | enhancement | CC: | jstein, maffblaster, sam |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Duncan
2020-10-23 13:57:10 UTC
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). rsync is also used by sys-kernel/linux-headers. |