# yeah, top-level 'use' sucks. I'd like to have it in 'src_install()' use binary && QA_PREBUILT="*" Sooo... why isn't it there, after all?
(In reply to Michał Górny from comment #0) > # yeah, top-level 'use' sucks. I'd like to have it in 'src_install()' > > use binary && QA_PREBUILT="*" > > > Sooo... why isn't it there, after all? Because moving that cutie to src_install() does not work. It does not seem to work even in pkg_setup() (if EBUILD_PHASE = setup is what I think): https://github.com/gentoo/portage/blob/master/bin/ebuild.sh#L708 But even if it would manpage does not hint at where I should actually put it to make it work. ::gentoo has no single example of setting QA_PREBUILT not at top-level. Guess it's not an accident. Easy to check. Patching it a bit: diff --git a/dev-lang/ghc/ghc-7.10.2-r1.ebuild b/dev-lang/ghc/ghc-7.10.2-r1.ebuild index fe3ce0d..3e545ba 100644 --- a/dev-lang/ghc/ghc-7.10.2-r1.ebuild +++ b/dev-lang/ghc/ghc-7.10.2-r1.ebuild @@ -109,5 +109,2 @@ REQUIRED_USE="?? ( ghcbootstrap binary )" -# yeah, top-level 'use' sucks. I'd like to have it in 'src_install()' -use binary && QA_PREBUILT="*" - # haskell libraries built with cabal in configure mode, #515354 @@ -321,2 +318,4 @@ pkg_setup() { + use binary && QA_PREBUILT="*" + if use ghcbootstrap; then @@ -564,2 +563,4 @@ src_compile() { src_install() { + use binary && QA_PREBUILT="*" + if use binary; then And trying (takes less than a minute): $ USE=binary ebuild ghc-7.10.2-r1.ebuild clean install * QA Notice: Pre-stripped files found: * /usr/lib64/ghc-7.10.2/unlit * /usr/lib64/ghc-7.10.2/ghc_I01how1S8noEugDz0meNiv/libHSghc-7.10.2-I01how1S8noEugDz0meNiv-ghc7.10.2.so ...
Well, another option is to set it unconditionally though we probably don't want that. So... another option is to use a separate -bin package like other ebuilds do ;-P.
(In reply to Michał Górny from comment #2) > Well, another option is to set it unconditionally though we probably don't > want that. So... another option is to use a separate -bin package like other > ebuilds do ;-P. It's a useful warning and i would not like to lose the signal. I'd rather leave a QA warning for USE=binary builds. GHC occasionally introduces wrong flag attributes on elf sections and those need to be caught and fixed. We did -bin ebuilds and stopped doing that in 2007. It's a maintenance nightmare. Mostly because haskell packages (libraries) require registration for a compiler installing them (/usr/lib/ghc-7.10.2.20151030/package.conf.d/). Having more than one compiler requires packages being rebuild for each of them. .ebuild code duplication across ghc/ghc-bin is not fun as well. It's one of the largest ebuilds in tree. I won't be smaller if it will have to handle presence of both bin and non-bin versions. Currently we are using subslots to trigger library rebuilds when GHC gets an upgrade. Introducing more providers is not trivial :) I'd rather wait when portage gets a sane fix for QA_ vars and move that one line to whatever is guaranteed to work.
You could do subslotted virtuals like we do for pypy. CC-ing dev-portage for QA* help.
So what's our plan here, considering Portage being fixed?
Once stable portage will support setting use binary && QA_PREBUILT="*" in phase functions I'll be happy to fix all the dev-lang/ghc ebuilds retroactively.
Meanwhile, you are shipping a broken ebuild to paludis users and are violating the spec. QA_PREBUILT is a portage-only variable with little to no meaning for the user.
(In reply to Julian Ospald (hasufell) from comment #7) > Meanwhile, you are shipping a broken ebuild to paludis users To be precise we ship it for 2 years: https://bugs.gentoo.org/431650 It's the first time I am told ghc ebuild is broken on paludis. Was it broken for all 2 years there or did paludis intentionally break their existing users in this timeframe? > and are violating the spec. I guess you are about https://dev.gentoo.org/~ulm/pms/head/pms.html 11.3.3.12 Use List Functions These functions provide behaviour based upon set or unset use flags. Ebuilds must not run any of these commands once the current phase function has returned. It is an error if an ebuild calls any of these functions in global scope. 'use' ... portage does not have a warning for this spec violation (filed https://bugs.gentoo.org/show_bug.cgi?id=572556 to track it) > QA_PREBUILT is a portage-only variable with little to no meaning for the > user. I consider myself as an user and QA_PREBUILT presence in ebuilds has very precise meaning for me as well as a "QA Notice: Pre-stripped files found" notice. bug #431650 clearly shows this variable is a part of QA process. I value that signal and would not like to lose it.
During metadata generation PMS requires that IUSE_EFFECTIVE is empty. Calling use under this condition must result in an error if EAPI=5. This is where paludis catches the error. Using the ebuild for other purposes than metadata generation still works. I have been told that FEATURES=qa turns QA warnings into errors, so we cannot get rid of QA_PREBUILT. On the other hand, global use is broken and we should remove it. So I second the proposal to set QA_PREBUILT unconditionally until portage is fixed in a way that makes it work on a non global scope.
Pushed move to pkg_setup() as: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=9bc66f191869fb05fcdd07973782b2097497a7fc Thanks!
