Installation of binary web-aplication fails if dev-lang/php version the package was built with is removed from the system: ============================================== camobap ~ # emerge -k cacti Calculating dependencies... done! >>> Emerging (1 of 1) net-analyzer/cacti-0.8.7b to / >>> Extracting info * Checking for required PHP feature(s) ... * * ERROR: net-analyzer/cacti-0.8.7b failed. * Call stack: * ebuild.sh, line 49: Called pkg_setup * environment, line 2539: Called require_php_with_use 'pkg_setup' 'pkg_setup' 'pkg_setup' 'cli' 'mysql' 'xml' * environment, line 2788: Called built_with_use 'session' 'pcre' * environment, line 322: Called die * The specific snippet of code: * [[ -z ${PKG} ]] && die "Unable to resolve $1 to an installed package"; * The die message: * Unable to resolve =dev-lang/php-5.2.5-r1 to an installed package * * If you need support, post the topmost build error, and the call stack if relevant. * A complete build log is located at '/var/tmp/portage/net-analyzer/cacti-0.8.7b/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/net-analyzer/cacti-0.8.7b/temp/environment'. * !!! Setup failed: 1 ============================================== At the same time I have dev-lang/php-5.2.5_p20080206-r3 installed. =dev-lang/php-5.2.5-r1 is taken from environment.bz2 so I'm not sure if this is portage or eclass bug, so CC'ing both. camobap ~ # emerge --info Portage 2.1.4.4 (default-linux/x86/2007.0, gcc-4.1.2, glibc-2.6.1-r0, 2.6.22-ovz005 i686) ================================================================= System uname: 2.6.22-ovz005 i686 Intel(R) Pentium(R) M processor 1700MHz Timestamp of tree: Sat, 23 Feb 2008 13:00:02 +0000 app-shells/bash: 3.2_p17-r1 dev-java/java-config: 1.3.7, 2.1.4 dev-lang/python: 2.4.4-r6 dev-python/pycrypto: 2.0.1-r6 sys-apps/baselayout: 1.12.11.1 sys-apps/sandbox: 1.2.18.1-r2 sys-devel/autoconf: 2.61-r1 sys-devel/automake: 1.10 sys-devel/binutils: 2.18-r1 sys-devel/gcc-config: 1.4.0-r4 sys-devel/libtool: 1.5.26 virtual/os-headers: 2.6.23-r3 ACCEPT_KEYWORDS="x86" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=i686 -pipe -mtune=i686" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/config" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/terminfo /etc/texmf/web2c /etc/udev/rules.d" CXXFLAGS="-O2 -march=i686 -pipe -mtune=i686" DISTDIR="/usr/portage/distfiles" FEATURES="buildpkg distlocks metadata-transfer parallel-fetch sandbox sfperms strict unmerge-orphans userfetch" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo" LANG="ru_RU.UTF-8" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X acl apache2 bash-completion berkdb bitmap-fonts bzip2 cli cracklib crypt cups dri fortran gdbm gpm iconv ipv6 isdnlog java kerberos ldap linuxthreads-tls midi mudflap mysql ncurses nls nptl nptlonly openmp pam pcre perl pic pppd python readline reflection session sockets spl sqlite ssl tcl tcpd threads truetype-fonts type1-fonts unicode userlocales vim-syntax x86 xml xorg zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1 emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" ELIBC="glibc" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" USERLAND="GNU" VIDEO_CARDS="apm ark chips cirrus cyrix dummy fbdev glint i128 i740 i810 imstt mach64 mga neomagic nsc nv r128 radeon rendition s3 s3virge savage siliconmotion sis sisusb tdfx tga trident tseng v4l vesa vga via vmware voodoo" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LC_ALL, LDFLAGS, LINGUAS, MAKEOPTS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS ==============================================
Shrug; from my POV this portage behaviour completely sucks. Imagine you RDEPEND on certain ebuild version since the previous ones do not have the flag; with binpkgs it's bound to fail since the flag won't be there. PHP_PKG=$(best_version =dev-lang/php-5*) is how is this set for PHP5 (same way for PHP4 but that's now masked). We need Bug 2272 fixed instead of hacking around built_with_use.
Created attachment 144422 [details, diff] depend.php.eclass.diff You can try this patch and see if it helps; if it doesn't, shrug... Relying upon environment.bz2 contents for variables can potentially cause tons of weird issues with tons of eclasses, grep $PORTDIR/eclass for -z/-n usage.
Jakub, no, that does not helps here. Still fails. And this is not a surprise as has_php() does not define PHP_PKG...
(In reply to comment #3) > Jakub, no, that does not helps here. Still fails. And this is not a surprise as > has_php() does not define PHP_PKG... It doesn't define PHP_PKG, but it calls uses_php${PHP_VERSION} which in turn sets PHP_PKG variable. I'm afraid a cached function from your binpkg will be used anyway, for current binpkgs this is totally a CANTFIX.
(In reply to comment #2) > You can try this patch and see if it helps; if it doesn't, shrug... Relying > upon environment.bz2 contents for variables can potentially cause tons of weird > issues with tons of eclasses, grep $PORTDIR/eclass for -z/-n usage. It shouldn't be too difficult to fix those kinds of issues. It might take a few weeks to flush all of them out since portage-2.1.4.4 is the first stable version to support it and that went stable just last week. (In reply to comment #4) > I'm afraid a cached function from your binpkg will be > used anyway, for current binpkgs this is totally a CANTFIX. Yeah, but it's well worth it for having bug 46223 fixed (affected installation of binary packages as well).
(In reply to comment #5) > It shouldn't be too difficult to fix those kinds of issues. It might take a few > weeks to flush all of them out since portage-2.1.4.4 is the first stable > version to support it and that went stable just last week. Shrug; feel free to commit the patch if you think it's the way to go. I'd rather leave [[ -z ${PHP_VERSION} ]] in place even if it suffers from the same issue since triplicating the overhead for each require_php_with_use check in an ebuild (some of ebuilds in the tree call this up to 4 times in a chain) really sucks.
I don't thing calling has_version 4 times is going to ruin anyone's day. I think better to be accurate than to shave off a few hundred milliseconds. If you want to optimize it to be a little faster then you'll have to do something to implement a staleness check so that it works correctly in all cases.
(In reply to comment #7) > I don't thing calling has_version 4 times is going to ruin anyone's day. I > think better to be accurate than to shave off a few hundred milliseconds. If > you want to optimize it to be a little faster then you'll have to do something > to implement a staleness check so that it works correctly in all cases. Well, for an ebuild that has 4 require_php_with_use checks, it will now call has_version 4 times, and best_version 4 times (for PHP5). It will call has_version 8 times if someone is on PHP4 still. Can't imagine any working 'staleness check' when portage behaves like this. I kinda don't understand how's similar behavior useful for phases like pkg_setup.
Still, calling it 8 times is better than having it die. It probably won't consume more than a few seconds which is pretty small in comparison to lots of other things.
(In reply to comment #7) > Can't imagine any working > 'staleness check' when portage behaves like this. In order to implement a working staleness check, some of the suggested workarounds mentioned in bug 154495 might be useful. For example, the pkg_setup() phase can store state in a variable at build time indicating that it has been run successfully. When it is invoked a second time at binary package installation time, it can check the state of such a variable and use that to deduce that certain cached values (such as PHP_PKG) need to be invalidated.
Shrug; the workaround for this crazy variables caching is in the tree. While there are bugs about portage that should sanitize environment, I don't see how's this consistent with portage caching all kind of irrelevant stuff in binpkgs.
Currently, we have no way to judge what is "irrelevant". It's possible for eclasses and ebuilds to set all kinds of variables at build time and expect that those variables will persist through to the installation phases. Certainly the functions defined by the ebuilds and eclasses need to persist (or at least a subset of them). The simplest solution is to persist all functions and variables.
