MAKEINFO='/gentoo/prefix32/bin/bash /export/scratch/gentoo-tmp/portage/sys-devel /flex-2.5.37/work/flex-2.5.37/missing --run makeinfo -I .' \ texi2dvi --pdf --batch flex.texi You don't have a working TeX binary (tex) installed anywhere in your PATH, and texi2dvi cannot proceed without one. If you want to use this script, you'll need to install TeX (if you don't have it) or change your PATH or TEX environment variable (if you do). See the --help output for more details. For information about obtaining TeX, please see http://www.tug.org. If you happen to be using Debian, you can get it with this command: apt-get install tetex-bin make[2]: *** [flex.pdf] Error 1
During make install, version.texi is updated: Making install in doc make[2]: Entering directory `/gentoo/prefix32/var/tmp/portage/sys-devel/flex-2.5.37/work/flex-2.5.37/doc' Updating ./version.texi restore=: && backupdir=".am$$" && \ am__cwd=`pwd` && CDPATH="${ZSH_VERSION+.}:" && cd . && \ rm -rf $backupdir && mkdir $backupdir && \ if (/gentoo/prefix32/bin/bash /gentoo/prefix32/var/tmp/portage/sys-devel/flex-2.5.37/work/flex-2.5.37/missing --run makeinfo --version) >/dev/null 2>&1; then \ for f in flex.info flex.info-[0-9] flex.info-[0-9][0-9] flex.i[0-9] flex.i[0-9][0-9]; do \ if test -f $f; then mv $f $backupdir; restore=mv; else :; fi; \ done; \ else :; fi && \ Which requires the pdf to be rebuilt.
This one is because of: doc/version.texi does have a dependency on toplevel configure, which gets updated by econf() when sed'ing CONFIG_SHELL into the shebang (since bug#308835). econf() really should restore the original timestamp here.
This should fix it: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=2a90b77f1606f4ab7b829672c87cba29670410e3
(In reply to comment #3) LGTM, even if I've thought of {touch -rconfigure tmp;sed -i configure;touch -rtmp [-m] configure} to not have to cope with permissions.
Okay, tweaked to re-use the same inode: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=75b469eace9a0dbd5187cb78531ed064ec29a461
(In reply to comment #3) > This should fix it: > > http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit; > h=2a90b77f1606f4ab7b829672c87cba29670410e3 You just pulled an embrace/extend on the standard. Revert it, fix the ebuild, and change the spec (eapi6) if you want this, or get all managers to carry the same fix.
I don't see any mention of CONFIG_SHELL in PMS. If it's not mentioned, then this fix is already in the "unspecified" realm.
(In reply to comment #7) > I don't see any mention of CONFIG_SHELL in PMS. If it's not mentioned, then > this fix is already in the "unspecified" realm. This is a shitty angle to try arguing on. PMS documents econf's behaviour; you're explicitly modifying that support to handle things beyond what is in the spec. Embrace. Extend. The end result of crap like this is that either third party managers have to monitor all portage commits to try and maintain compatibility, or our managers get labeled as 'broken' because portage extends the spec and ebuilds in the tree wind up relying on that behaviour. Pretty much either restore it to PMS standard, or take it to the council- you have no idea how tired I am of stuff like this sliding in and breaking pkgcore, I certainly wouldn't mind the council reiterating that portage is supposed to play nice on this front. ;)
Do other package managers even support CONFIG_SHELL?
This is fixed in 2.1.11.51 and 2.2.0_alpha162.
(In reply to comment #9) > Do other package managers even support CONFIG_SHELL? Nope, and that's kind of the fucking point. #308835 changed portage prefix support for *all* prefix aware EAPIs. Ebuilds rely on CONFIG_SHELL to automatically correct configure scripts- rather than the prefix'd ebuilds fixing the configure scripts by default. That literally means that those EAPI=3,4,5 ebuilds will only reliably work for portage, while failing for PMS complaint non-portage managers. Even more fun, if you take a look at the bsd profile it looks like they were relying on it for a while too- this embrace/extend wasn't limited to just prefix targets. The original decree of pms/portage was that portage had to match the spec- not extend EAPI=N, match it. Yes, PMS doesn't document that you cannot shove something like CONFIG_SHELL in- letter of the law, you're safe. Intention of the rules, not even remotely. Either way, bumping this up to the council; nothing is going to change continuing to argue over this, and I'm no longer willing to keep monitoring portage commits just to try and ensure compatibility hasn't been broken (or to ensure that I exactly match portage behaviour rather than the standard for where things have been extended that PMS ebuilds will come to rely on). I honestly don't care what is done in non standard EAPIs- that's fair game. Standardized is a separate story and is an ongoing source of gotchas over the years that needs to stop.
Okay, so let's move the party over to bug 308835 then?
