we have tools that often generate symlinks or helper files that are then, from the perspective of portage, orphaned. if we extended the CONTENTS file slightly, and added an API with portageq for updating that file, it'd lead to much better tracking of these various files. we have symlinks in /usr/bin/, /usr/include/, /usr/lib/, /usr/share/doc/man/, etc... that'd all benefit. just run: qfile -o /bin/* /usr/bin/* to see all the orphaned files. i'd propose the new keyword "gen" and it'd just have one value -- the path that is being tracked. no mtime, hash, etc... tooling would use it for informational purposes, but they would not get picked up when e.g. creating binary packages. portageq would then have a simple API like: contents_gen <eroot> <category/package> <add|del|set> <paths>
