Ebuild for UDNS, an async-capable DNS stub resolver library. Reproducible: Always Steps to Reproduce: net-im/jabberd2-2.2.0 (not yet released) depends on this
Created attachment 153625 [details] UDNS ebuild
- The ebuild header is invalid¹ - no dependencies... - don't hardcode /usr/lib, use $(get_libdir) [1] http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2&chap=3
- There is absolutely no link to that document anywhere on http://www.gentoo.org/doc/en/ -> http://www.gentoo.org/doc/en/?catid=gentoodev -> http://www.gentoo.org/doc/en/ebuild-submit.xml - There are no dependencies. - I can't even find get_libdir in http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2&chap=1, I just copied another ebuild.
Added to the tree.
This ebuild appears to have been broken by someone who doesn't understand that this is a library - it should not make use of the 'static' USE flag, the .a file should always be installed.
It's also missing ~x86, which I had in my original file.
@Krzysiek: Simon is right, using the static use flag to control installation of the static lib is misuse of this use flag. Revert, please. gentoofan: Seeing this "improvement" from you and https://bugs.gentoo.org/show_bug.cgi?id=225673#c5 I thought it's better to cc you.
(In reply to comment #6) > It's also missing ~x86, which I had in my original file. *YOU*, no me - I'm on amd64, so it got ~amd64 and a KEYWORDREQ bug: bug #225801 'static' removed.
Is there some document that says not to use the static USE flag for these circumstances? I ask because the udns package isn't broken by it's use. Jabberd2 compiles and links just fine without the static archive.
(In reply to comment #9) > Is there some document that says not to use the static USE flag for these > circumstances? I don't think this is documented anywhere. It might, though. The flags only purpose is creating static apps. (In reply to comment #9) > I ask because the udns package isn't broken by it's use. Jabberd2 compiles and > links just fine without the static archive. Irrelevant for the matter. Personally I'd love to see a system consisting of applications linking shared libs (almost) exclusively, but I fear that this is a long and burdensome way to go for Linux distributions
