While testing kensington's depcheck and trying to work it into a QA check for portage I came across what I thought was an interesting false positive: * Messages for package app-cdr/cdrtools-3.01_alpha17: * /usr/lib64/librscg.so.1.0 links to /lib64/libcap.so.2 * Missing RDEPEND on sys-libs/libcap Upon further investigation, it looks like fcaps.eclass only sets libcap as a DEPEND, but in this case it gets linked in and is needed at runtime. Is this an unusual case for libcap to actually be linked in, or should the eclass be setting RDEPEND as well? I don't know anything about filecaps or libcap so I'm assigning this to the person who has made all the recent commits, and cc:ing the retired developer who wrote the eclass originally. Please correct my mistakes at will :-)
fcaps.eclass uses the tools from sys-libs/libcap to set capabilities on executables as per the directions in the ebuilds that use the eclass. The eclass doesn't purport to handle the use of sys-libs/libcap for other purposes, like linking against its libraries. Those ebuilds should set their own dependencies properly.
After a slightly longer explaination of how filecaps work (thanks aballier) This is only a missing dep in the cdrtools ebuild. libcap is needed for fcaps.eclass to set filecaps but is not nessesarily needed by everything which uses filecaps once this initial setup is done. Adjusted cdrtools ebuild accordingly. Thanks!
i've updated the descriptions in the various files: http://sources.gentoo.org/profiles/use.desc?r1=1.522&r2=1.523 http://sources.gentoo.org/eclass/fcaps.eclass?r1=1.10&r2=1.11
Thanks vapier, that will help avoid confusion like mine.
