it is a common mistake to use doins instead of newicon or doicon. repoman could find 99% of these with one bash line: grep "insinto.*icons" *.ebuild && echo "Repoman feels suddenly very bad: Please use doicon or newicon to install icons" qgrep -N -e "insinto.*icons" lists 114 packages with the problem. Including famous ones like www-client/firefox and net-analyzer/wireshark. Reproducible: Always
newicon and doicon are defined in the eutils eclass. https://devmanual.gentoo.org/eclass-reference/eutils.eclass/ AFAIK there are no further EAPI restrictions in this case.
This seems a bit dubious to me. doicon/newicon are convenience functions. If an ebuild calls doins/newins in an appropriate way instead, I don't see any reason to flag that as a QA failure.
Mike, that is interesting. When I discussed this with other developers before writing the ticket, the tenor was "never use doins for icons". Perhaps we should at least clarify our documentation on this. Best, JS
IMHO, there is nothing wrong with using doins to install icons. You would have a valid argument if doicon was a package manager function. There also is a tradeoff between using doicon and inheriting a large eclass, or using insinto and doins which may require one additional of code. I would leave that decision to the maintainer.
repoman support has been removed per bug 835013. Please file a new bug (or, I suppose, reopen this one) if you feel this check is still applicable to pkgcheck and doesn't already exist.
I still think this isn't valid, by comment #4.
(In reply to Ulrich Müller from comment #6) > I still think this isn't valid, by comment #4. Fine with me, I just wanted to do the closing separate from the moving.
