Title says it all really... I'm just mildly baffled as to the reason for this. Should the unifont ebuild *really* depend on chkfontpath? Should unifont be package.mask'ed too? I have CC'ed the ebuild submitter in the hope this "bug" can be shot down quickly and not clutter up the place. Hope that's okay.
*** Bug 37758 has been marked as a duplicate of this bug. ***
If we are not to unmask chkfontpath I'll remove chkfontpath from unifont's ebuild (it isn't needed unless we want to automate installation anyway). I knew it was marked unstable and committed unifont but didn't notice chkfontpath was package masked (moreover, I didn't know that foser didn't like the idea of making use of it then)
Ideas here?
Definitely it doesn't need chkfontpath, so I'll remove chkfontpath from DEPEND and make some modification to unifont's ebuild tomorrow if nobody is strongly against it. (In addition I'm going to mask current chkfontpath for the sake of chkfontpath)
I added unifont-1.0-r1, which doesn't depend on chkfontpath and p.masked unifont-1.0 accordingly.
