ebuild for reverse-transfer.sh per prior conversation with zmedico bug is for tracking. Reproducible: Always
(In reply to comment #0) > per prior conversation with zmedico bug is for tracking. Reassigning then...
I working on a new tool the will work something like this: Usage: egencache [options] --generate | --update [atom] ... Options: -h, --help show this help message and exit --update update metadata/cache/, generate as necessary --generate generate cache only --repo=REPO operate on the named repo (default is one located at $PORTDIR) --jobs=JOBS max ebuild processes to spawn --load-average=LOAD max load allowed when spawning multiple jobs --rsync enable workaround for bug 139134 when (use with --update) Typical usage will be simply `egencache --update`, which will update metadata/cache/ and generate cache as necessary. It will bail out immediately if you don't have FEATURES=metadata-transfer enabled. In the future we can drop the metadata-transfer requirement, after the cache format has been extended to include eclass digests as described here: http://archives.gentoo.org/gentoo-dev/msg_cfa80e33ee5fa6f854120ddfb9b468b3.xml The program will take atom arguments, so you will be able to update cache for individual packages, as requested in bug #261528. The --rsync option will cause ebuild timestamps to be bumped as a workaround for bug 139134. This option should only be needed for distribution via something like rsync, which relies on timestamps and file sizes to detect changes. You won't need it with git since that uses a more thorough mechanism which allows it to detect changed inode numbers (described in racy-git.txt in the git technical docs).
*** Bug 261528 has been marked as a duplicate of this bug. ***
There is an initial version of the egencache script in svn r13260. It only has the most basic functionality now, and more features will be added soon.
This is fixed in 2.2_rc29.
This is fixed in 2.1.6.12.
