SYMPTOM: x86_64-pc-linux-gnu-gcc -o cvsps debug.o hash.o sio.o tcpsocket.o paths.o cvsps.o util.o stats.o cvsclient.o list_sort.o -march=native -pipe -O2 -mfpmath=sse -Wl,--as-needed -Wl,-O1 -Wl,--hash-style=gnu -Wl,--sort-common -lz make: *** No rule to make target 'cvsps.asc', needed by 'cvsps.1'. Stop. !!! ERROR in dev-vcs/cvsps-3.13-r1::gentoo: !!! In /usr/libexec/paludis/utils/emake at line 30 !!! emake returned error 2 CURE: The ebuild modifies upstream to move cvsps.asc to cvsps-3.asc This is probably done for slot'ng reasons. The man-page itself is sed'd by the ebuild to reflect this, but the Makefile is not updated, looking for cvsps.asc when it should look for cvsps-3.asc. Modifying the ebuild to sed the Makefile as well fixes this bug. Reproducible: Always
Created attachment 394020 [details] paludis/cave build log
Created attachment 394026 [details, diff] cvsps-3.13-r1.ebuild.patch Ensure MAKEOPTS is available to src_compile() and src_install()..
See PMS section 11.2: https://dev.gentoo.org/~ulm/pms/head/pms.html#x1-12200011.2 This bug only hits users if neither /etc/paludis/bashrc nor /etc/portage/make.conf define MAKEOPTS variable. Usually MAKEOPTS has a definition within these, but ebuilds _must not_ depend on it. PMS section 11.2 states "Global variables must only contain invariant values" I assume variables defined in either /etc/paludis/bashrc or /etc/portage/make.conf are not "global", but just "default-scope" variables wrt to PMS. Else paludis is broken for handing modified 'globals' down the call sequence. PMS section 11.2 also states "Exported and default scope variables are saved between functions." This means even if the PM does not find a "default-scope" MAKEOPTS in make.conf or paludis/bashrc it _must_ save a MAKEOPTS definition found (only) in src_prepare() of this ebuild to the ebuild environment. Reproducable behavior here is: for PALUDIS: - If MAKEOPTS is defined in paludis/bashrc, then further modifications to the var within the ebuild are saved to the ebuild environment (correct wrt PMS) - If MAKEOPTS is undefined in paludis/bashrc, then the variable will not be saved to the ebuild env by the PM, unless it is exported using an explicit "export" statement. (seems to be incorrect wrt PMS) - Arbitrary variable names defined within an ebuild function are saved to the ebuild env without the need to use an explicit "export" statement. (correct wrt PMS, tested using variable name FOOBAR) for PORTAGE: - If MAKEOPTS is undefined in etc/make.conf, then the variable will not be saved to the ebuild env by the PM, unless it is exported using an explicit "export" statement. (seems to be incorrect wrt PMS) Depending on MAKEOPTS being a "global" or "default-scope" variable, PMS demands following behavior: CASE 1) MAKEOPTS is treated as a "global" by the PM. Then the ebuild must not depend on modifications to this variable being saved to the ebuild environment, as "Global variables must only contain invariant values" CASE 2) MAKEOPTS is treated as a "default-scope" by the PM. Then it must not matter if it's defined in make.conf or not and it must not need an explicit "export" statement, as "Exported and default scope variables are (both) saved between functions."
Created attachment 394030 [details] portage/emerge build log cat /var/tmp/portage/dev-vcs/cvsps-3.13-r1/temp/environment | grep -B 6 -A 3 MAKEOPTS declare -x LIBDIR_x86="lib32" declare -x LIBDIR_x86_fbsd="lib32" declare -x LIBOPTIONS="-m0644" declare -x LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" declare -x LICENSE="GPL-2" declare -x MAIL="/var/mail/root" declare -- MAKEOPTS=" PROG=cvsps-3" declare -x MBK_C4_LIB="./cellsC4" declare -x MBK_CATAL_NAME="CATAL" declare -x MBK_CATA_LIB=".:/usr/share/alliance/cells/sxlib:/usr/share/alliance/cells/dp_sxlib:/usr/share/alliance/cells/rflib:/usr/share/alliance/cells/rf2lib:/usr/share/alliance/cells/ramlib:/usr/share/alliance/cells/romlib:/usr/share/alliance/cells/pxlib:/usr/share/alliance/cells/padlib" -- src_prepare () { local gentoo_name=${PN}-3; epatch "${FILESDIR}"/${P}-make.patch; mv ${PN}.asc ${gentoo_name}.asc || die; sed -i "s/${PN}/${gentoo_name}/g" ${gentoo_name}.asc || die; MAKEOPTS=" PROG=${gentoo_name}"; tc-export CC; export prefix="${EPREFIX}"/usr }
(In reply to cmuelle8 from comment #4) > declare -- MAKEOPTS=" PROG=cvsps-3" Deducting from the difference of this line to the other declares I think it's safe to deduct that MAKEOPTS is treated special. It's hard to tell, whether it's Again, citing the PMS at https://dev.gentoo.org/~ulm/pms/head/pms.html#x1-12200011.2 there are four different types of variable scopes: - "local" (i.e. not saved to ebuild env) - "default" (saved to ebuild env) - "exported" (saved to ebuild env) - "global" (saved to ebuild env, invariant, i.e. maybe modified/shadowed locally, but the modification will not be saved to the ebuild env) an additional note says "Variables with special meanings to the PM are excluded from this rule." which adds a pseudo-scope to the list above, lets name it - "special" Depending on which scope MAKEOPTS actually belongs to, either the ebuild or the PMs ought to be fixed.
Regardless of whether or not PMs are at fault, adding export MAKEOPTS to src_prepare() will be a good workaround ("prefix" and "CC" are explicitly exported to the ebuild env as well). Then, to clarify the status of MAKEOPTS (special/global/default scope) and verify correct handling by PMs checking (A) make.conf defined (B) undefined (first definition within an ebuild function) cases, might be a topic for another bug ticket.. I presume for case (A) if make.conf defines are globals, it's buggy that the PM saves modifications done to these vars within ebuild functions to the ebuild environment. (unless explicit export used) (B) it's buggy that the PM does not treat MAKEOPTS as "default scope".
There's also a mailing thread about MAKEOPTS here (dating 2007): https://www.mail-archive.com/gentoo-dev@lists.gentoo.org/msg24804.html .. but it covers a slightly different topic, that is setting MAKEOPTS within global scope of the ebuild, not within ebuild functions.
Yeah, thanks for the detailed analysis. Clobbering MAKEOPTS was a bad idea. paludis always tries hard to break user's system (and it's good for ebuild quality!) Sadly it does not print meaningful diagnostics when does so :) Maybe paludis does, but in some QA log? I've pushed target rename as it should have beenin the fist place as: > 15 Jan 2015; Sergei Trofimovich <slyfox@gentoo.org> cvsps-3.13-r1.ebuild: > Don't clobber MAKEOPTS on paludis (bug #536680 by cmuelle8). Thanks! I didn't tests it on paludis, so please reopen if won't help. The fix: --- cvsps-3.13-r1.ebuild 6 Oct 2014 18:38:36 -0000 1.2 +++ cvsps-3.13-r1.ebuild 15 Jan 2015 19:55:56 -0000 @@ -27,7 +27,7 @@ epatch "${FILESDIR}"/${P}-make.patch mv ${PN}.asc ${gentoo_name}.asc || die sed -i "s/${PN}/${gentoo_name}/g" ${gentoo_name}.asc || die - MAKEOPTS+=" PROG=${gentoo_name}" + sed -i "s/PROG = cvsps/PROG = ${gentoo_name}/" Makefile || die tc-export CC export prefix="${EPREFIX}"/usr
Thanks for the quick response. Works with paludis as well.
