Ticket #1078 (closed ebuild-defect: upstream)

Opened 9 years ago

Last modified 9 years ago

Cave wrongly resolves PHP_TARGETS in dev-php5/suhosin-

Reported by: ojezu Owned by:
Priority: MinorRelease Milestone: cave Basic Functionality
Component: clients/cave Version: 0.56.2
Keywords: suhosin php PHP_TARGETS Cc:
Blocked By: Blocking:
Distribution: Gentoo


Cave wrongly resolves dependencies of dev-php5/suhosin- requiring PHP_TARGETS: php5-2 to be set. I think cave gets confused by the following suhosin's deps:

$ cave show suhosin -c (extract)

|| (

$ cave resolve suhosin (extract)

I cannot proceed without being permitted to do the following:

n   dev-php5/suhosin:0::gentoo to ::installed
    "Suhosin is an advanced protection system for PHP installations."
    Need changes for: PHP_TARGETS: php5-2 No changes needed: PHP_TARGETS: php5-3 build_options: -optional_tests split strip -trace -preserve_work
    Reasons requiring changes: restarted because of dev-php5/suhosin Reasons: target, dev-php5/suhosin
    Cannot proceed without: being reconfigured

paludis reports no errors pretending to install suhosin.

$ cave info suhosin

Package Manager Information:
    Package Name              paludis
    Package Version           0.56.2
    Build Date                2011-01-08T01:42:41+0100
    Built with CXX            x86_64-pc-linux-gnu-g++ 4.4.4
    Built with CXXFLAGS        -march=native -O2 -pipe -pedantic
    Built with LDFLAGS        -Wl,-O2

Environment Information:
    Format                    paludis
    Config dir                /etc/paludis
    Root                      /
    System Root               /
    World file                /var/db/pkg/world

Repository installed-virtuals:
    format                    installed_virtuals
    root                      /

Repository virtuals:
    format                    virtuals

Repository gentoo:
    format                    e
    location                  /usr/portage
    builddir                  /var/tmp/paludis
    cache                     /usr/portage/metadata/cache
    distdir                   /usr/portage/distfiles
    eapi_when_unknown         0
    eapi_when_unspecified     0
    eclassdirs                /usr/portage/eclass
    layout                    traditional
    names_cache               /usr/portage/.cache/names
    newsdir                   /usr/portage/metadata/news
    profile_eapi_when_unspecified 0
    profile_layout            traditional
    profiles                  /usr/portage/profiles/default/linux/amd64/10.0/no-multilib
    securitydir               /usr/portage/metadata/glsa
    setsdir                   /usr/portage/sets
    sync                      rsync://rsync.gentoo.org/gentoo-portage
    use_manifest              use
    write_cache               /var/cache/paludis/metadata
    Package information
        app-admin/eselect-compiler (none)
        app-shells/bash       4.1_p7
        dev-java/java-config  (none)
        dev-lang/python       2.6.6-r1 3.1.2-r4
        dev-util/ccache       (none)
        dev-util/cmake        2.8.1-r2
        dev-util/confcache    (none)
        sys-apps/baselayout   1.12.13
        sys-apps/openrc       (none)
        sys-apps/sandbox      2.4
        sys-devel/autoconf    2.65-r1
        sys-devel/automake    1.10.3 1.11.1
        sys-devel/binutils    2.20.1-r1
        sys-devel/gcc         4.3.4 4.4.4-r2
        sys-devel/gcc-config  1.4.1
        sys-devel/libtool     2.2.10
        sys-devel/make        3.81-r2
        virtual/os-headers    2.6.30-r1 (for sys-kernel/linux-headers::installed)

Repository installed:
    format                    vdb
    location                  /var/db/pkg
    builddir                  /var/tmp/paludis
    eapi_when_unknown         0
    names_cache               /var/db/pkg/.cache/names
    provides_cache            /var/db/pkg/.cache/provides
    root                      /

Extra Information for dev-php5/suhosin-
cave@1294484549: [WARNING e.ebuild.userpriv_disabled] In thread ID '28799':
  ... In program cave info suhosin:
  ... When infoing 'dev-php5/suhosin-':
  ... When checking permissions on '/var/tmp/paludis' for userpriv:
  ... Directory '/var/tmp/paludis' does not have group write permission, cannot enable userpriv
        >>> Running ebuild phase killold as paludisbuild:paludisbuild...
        >>> Starting builtin_killold
        >>> Done builtin_killold
        >>> Completed ebuild phase killold
        >>> Running ebuild phases initmisc infovars as paludisbuild:paludisbuild...
        >>> Starting builtin_initmisc
        >>> Done builtin_initmisc
        >>> Starting builtin_infovars
        CFLAGS=-march=native -O2 -pipe
        CXXFLAGS=-march=native -O2 -pipe
        LINGUAS=en en_GB
        USE=amd64 alsa_pcm_plugins_adpcm alsa_pcm_plugins_alaw alsa_pcm_plugins_asym alsa_pcm_plugins_copy alsa_pcm_plugins_dmix alsa_pcm_plugins_dshare alsa_pcm_plugins_dsnoop alsa_pcm_plugins_empty alsa_pcm_plugins_extplug alsa_pcm_plugins_file alsa_pcm_plugins_hooks alsa_pcm_plugins_iec958 alsa_pcm_plugins_ioplug alsa_pcm_plugins_ladspa alsa_pcm_plugins_lfloat alsa_pcm_plugins_linear alsa_pcm_plugins_meter alsa_pcm_plugins_mmap_emul alsa_pcm_plugins_mulaw alsa_pcm_plugins_multi alsa_pcm_plugins_null alsa_pcm_plugins_plug alsa_pcm_plugins_rate alsa_pcm_plugins_route alsa_pcm_plugins_share alsa_pcm_plugins_shm alsa_pcm_plugins_softvol apache2_modules_actions apache2_modules_alias apache2_modules_auth_basic apache2_modules_authn_alias apache2_modules_authn_anon apache2_modules_authn_dbm apache2_modules_authn_default apache2_modules_authn_file apache2_modules_authz_dbm apache2_modules_authz_default apache2_modules_authz_groupfile apache2_modules_authz_host apache2_modules_authz_owner apache2_modules_authz_user apache2_modules_autoindex apache2_modules_cache apache2_modules_cgi apache2_modules_cgid apache2_modules_dav apache2_modules_dav_fs apache2_modules_dav_lock apache2_modules_deflate apache2_modules_dir apache2_modules_disk_cache apache2_modules_env apache2_modules_expires apache2_modules_ext_filter apache2_modules_file_cache apache2_modules_filter apache2_modules_headers apache2_modules_include apache2_modules_info apache2_modules_log_config apache2_modules_logio apache2_modules_mem_cache apache2_modules_mime apache2_modules_mime_magic apache2_modules_negotiation apache2_modules_rewrite apache2_modules_setenvif apache2_modules_speling apache2_modules_status apache2_modules_unique_id apache2_modules_userdir apache2_modules_usertrack apache2_modules_vhost_alias collectd_plugins_df collectd_plugins_interface collectd_plugins_irq collectd_plugins_load collectd_plugins_memory collectd_plugins_rrdtool collectd_plugins_swap collectd_plugins_syslog elibc_glibc gpsd_protocols_aivdm gpsd_protocols_ashtech gpsd_protocols_earthmate gpsd_protocols_evermore gpsd_protocols_fv18 gpsd_protocols_garmin gpsd_protocols_garmintxt gpsd_protocols_gpsclock gpsd_protocols_itrax gpsd_protocols_mtk3301 gpsd_protocols_navcom gpsd_protocols_nmea gpsd_protocols_ntrip gpsd_protocols_oceanserver gpsd_protocols_oldstyle gpsd_protocols_oncore gpsd_protocols_rtcm104v2 gpsd_protocols_rtcm104v3 gpsd_protocols_sirf gpsd_protocols_superstar2 gpsd_protocols_timing gpsd_protocols_tnt gpsd_protocols_tripmate gpsd_protocols_tsip gpsd_protocols_ubx input_devices_keyboard kernel_linux lcd_devices_bayrad lcd_devices_cfontz lcd_devices_cfontz633 lcd_devices_glk lcd_devices_hd44780 lcd_devices_lb216 lcd_devices_lcdm001 lcd_devices_mtxorb lcd_devices_ncurses lcd_devices_text linguas_en linguas_en_GB php_targets_php5-3 ruby_targets_ruby18 sane_backends_hp sane_backends_hp4200 sane_backends_net sane_backends_plustek userland_GNU video_cards_vesa xtables_addons_account xtables_addons_chaos xtables_addons_condition xtables_addons_delude xtables_addons_dhcpmac xtables_addons_fuzzy xtables_addons_geoip xtables_addons_iface xtables_addons_ipmark xtables_addons_ipp2p xtables_addons_ipset xtables_addons_ipv4options xtables_addons_length2 xtables_addons_logmark xtables_addons_lscan xtables_addons_pknock xtables_addons_psd xtables_addons_quota2 xtables_addons_rawnat xtables_addons_steal xtables_addons_sysrq xtables_addons_tarpit xtables_addons_tee amd64 
        >>> Done builtin_infovars
        >>> Completed ebuild phases initmisc infovars
        >>> Running ebuild phase tidyup as paludisbuild:paludisbuild...
        >>> Starting builtin_tidyup
        rm -fr /var/tmp/paludis/dev-php5-suhosin-
        >>> Done builtin_tidyup
        >>> Completed ebuild phase tidyup

Change History

comment:1 Changed 9 years ago by ciaranm

  • Status changed from new to closed
  • Type changed from defect to ebuild-defect
  • Resolution set to upstream

The bug's in the ebuild, not cave. || ( a b ) means "prefer a, but b is also allowed". You need to get upstream to fix the dependency. You can point them to this for an explanation:


comment:2 Changed 9 years ago by ojezu

  • Status changed from closed to reopened
  • Resolution upstream deleted
If in
( a b ) b is allowed, b is set and a is not, that means package should be installed without need to change a. Cave should install it with PHP_TARGETS: -php5-2 php5-3, which is not preferred but ALLOWED. I set PHP_TARGETS and I know what I want. If it is allowed, there is absolutely no reason for cave to block such an install.

comment:3 Changed 9 years ago by ciaranm

  • Status changed from reopened to closed
  • Resolution set to upstream

The dep's backwards. Get that fixed. If after that you still have an issue, then I'll look at it some more.

comment:4 Changed 9 years ago by ojezu

  • Status changed from closed to reopened
  • Type changed from ebuild-defect to defect
  • Resolution upstream deleted

All right, let's do it according to gentoo-dev step by step

How should a dependency like || ( a b c ) be interpreted?

Traditionally, it's been described as something like:

* if a matches an installed package, a
* otherwise, if b matches an installed package, b
* otherwise, if c matches an installed package, c
* otherwise, if a is installable, a
* otherwise, if b is installable, b
* otherwise, if c is installable, c
* otherwise, error

In my case it looks something like:
PHP_TARGETS: -5.2 5.3
a stands for =dev-php5/suhosin-[php_targets_php5-2]
b stands for =dev-php5/suhosin-[php_targets_php5-3]

|| (a b)

  • if a matches an installed package, a - no, it does not.
  • otherwise, if b matches an installed package, b - neither
  • otherwise, if a is installable, a - it is not
  • otherwise, if b is installable, b - bingo! I should do b!
  • otherwise, error never reached

The problem isn't that dep is backwards, the problem is cave forces me to do a which is not installable, while b is installable! If the dep was php-5.3 first people who want only php-5.2 with suhosin installed, would have this problem instead of me! Even if the ebuild will be "repaired" the problem won't be fixed, only shifted from php-5.3+suhosin to php-5.2+suhosin!

comment:5 Changed 9 years ago by ciaranm

  • Status changed from reopened to closed
  • Type changed from defect to ebuild-defect
  • Resolution set to upstream

No, the problem is not what you think it is. The problem is that you have something else that's also after 5.2. However, you won't get useful --explain output until you fix the dependency.

comment:6 Changed 9 years ago by ojezu

In order to "fix" dependency one has to modify the php-ext-source-r2.eclass due to suhosin setting only DEPEND="dev-lang/php[unicode]" directtly, while rest of the deps is set via calling inherit php-ext-source-r2. Specifically order of php versions in USE_PHP (eclass is broken?) has to be changed. When I changed USE_PHP to "php-5.3 php-5.2" from "php-5.2 php5.3", so the dependency order of suhosin is "right", cave indeed resolved suhosin as I wanted. However, when I changed PHP_TARGETS from "-php-5.2 php-5.3" to "php-5.2 -php-5.3" (trying to imitate an user who wants only php-5.2) the problem appeared again, this time cave producing:

I cannot proceed without being permitted to do the following:

n   dev-php5/suhosin:0::gentoo to ::installed
    "Suhosin is an advanced protection system for PHP installations."
    Need changes for: PHP_TARGETS: php5-3 No changes needed: PHP_TARGETS: php5-2 build_options: -optional_tests split strip -trace -preserve_work
    Reasons requiring changes: restarted because of dev-php5/suhosin Reasons: target, dev-php5/suhosin
    Cannot proceed without: being reconfigured

Just as I predicted. In conclusion, is it bug in cave resolver or is eclass broken?

comment:7 Changed 9 years ago by ciaranm

It's a combination of the eclass being broken and, most likely, there being a second dependency in there that you haven't noticed that's also causing problems.

Last time this cropped up it was because of virtual/httpd-php:5.2 still being installed. But there are plenty of other things that can cause it too.

comment:8 Changed 9 years ago by ojezu

Well, there is no second dependency. I can say it for sure, since I blocked <php-5.3, removed suhosin from world, and successfully did

cave resolve -cx world

Moreover, I see no way to rewrite eclass "properly" without hacks, so it works in any scenario (install 5.2 only, 5.3 only, both 5.2 5.3). I still consider this as a bug and I think we should get someone else to judge between us. I think it is the same bug as  http://bugs.gentoo.org/343961 . Although that one was closed, it seems it was misunderstanding. dev-php5/xdebug-2.1.0-r1 solved problem for emerge, not for cave (the bug happens for dev-php5/xdebug-2.1.0-r1 at my machine too).

comment:9 Changed 9 years ago by ciaranm

The issue isn't what you think it is. Given || ( a b ) , if there aren't any other factors involved, we'll go with b over a if a is masked and b isn't. Thus, there's something else there too that you're not telling us, and that something else could well be a second
( ) dependency that's also backwards.

In any case, the eclass must be fixed. Best versions leftmost.

comment:10 Changed 9 years ago by ojezu

So, what proper deps should be, so suhosin php-5.2 only or php-5.3 only install is possible with cave? Current run dependencies are:

|| (
php_targets_php5-2? (
php_targets_php5-3? (

comment:11 Changed 9 years ago by ciaranm

Best leftmost. But note that cave will bring in new slots of things you have installed anyway, so you'll end up with 5.3 regardless.

comment:12 Changed 9 years ago by ojezu

If the best are leftmost, installation for php-5.2 only won't be possible, as I have already pointed out. Never mind the other things, let's just assume suhosin is the only thing in my world spec that depends on php.

comment:13 Changed 9 years ago by ciaranm

If you want to keep things locked to an older slot, you need to either always use a whole load of extra options to cave, or mask the newer slot. The default options for cave are to bring in newer slots most of the time.

comment:14 Changed 9 years ago by ojezu

Then what is PHP_TARGETS for? Isn't it for specifying what php-related slots I want to be pulled in? Does cave take PHP_TARGETS into account while deciding between


=dev-php5/suhosin-[php_targets_php5-2] =dev-php5/suhosin-[php_targets_php5-3]

)}}} After all, it's what that variable is for, isn't it? Rather for user to decide what should system do than for system to decide what should user do? And in case of suhosin workaround is not as simple as masking installation slot, because suhosin is not mulit-slot. It only takes PHP_TARGETS to adjust to php slots installed in the system.

It seems cave rather than taking in account use flags while deciding, it recommends changing them and refuses further operation. There are situations in which this comes as a feature (e.g. page you linked, paragraph about libX11), but sometimes as a side-effect of delivering an idiot-proof system it delivers unconfigurable one. Maybe solution would be different treating of "native" use flags and keywords generated form things like PHP_TARGETS.

comment:15 Changed 9 years ago by ciaranm

PHP_TARGETS does not specify which PHP slots you want pulled in. It specifies which PHP targets packages should be built against, and it specifies which PHP slots are required as dependencies. The --slots and --target-slots options to cave resolve control which slots are pulled in.

You're also still wrong about how cave decides which bit of a
( ) branch to pull in. If you're looking to understand how it works, I suggest you completely forget about PHP and come up with some minimal test cases. Your problem here is that there are more dependencies involved than you think there are, and you're making assumptions about how the resolver works without understanding what you're giving it as input.

comment:16 Changed 9 years ago by ojezu

"PHP_TARGETS does not specify which PHP slots you want pulled in." I know that, if you want me to speak in strict terms, then speak strict terms too.

For dev-php5/suhosin:0::(install_to_slash):
    The following constraints were in action:
      * =dev-php5/suhosin-[php_targets_php5-2(-)], use existing if possible, installing to /
        Because of restarted because of =dev-php5/suhosin-[php_targets_php5-2] from dev-php5/suhosin-, key 'Run dependencies', labelled 'RDEPEND' (originally || ( =dev-php5/suhosin-[php_targets_php5-2] =dev-php5/suhosin-[php_targets_php5-3] ))
      * dev-php5/suhosin, never using existing, installing to /
        Because of target
      * =dev-php5/suhosin-[php_targets_php5-2], use existing if possible, installing to /
        Because of =dev-php5/suhosin-[php_targets_php5-2] from dev-php5/suhosin-, key 'Run dependencies', labelled 'RDEPEND' (originally || ( =dev-php5/suhosin-[php_targets_php5-2] =dev-php5/suhosin-[php_targets_php5-3] ))

What is that resolver magic making it select what it selects different than taking the left-most option? Why on earth changing order of USE_PHP in eclass, and thus changing the left-most option in the OR clause, would change decision to the new left-most solution if there was some sophisticated deciding process behind the scenes? It just takes the left-most because it is preferred, and doesn't take into account that it is not installable in current USE, PHP_TARGETS APACHE_MODULES etc. configuration, but other options are. Thanks to you I get why this is often seen as a feature, but in this case it is a bug. I specify PHP_TARGETS packages should be build against AND THEY SHOULD BE BUILD AGAINST THESE TARGETS even if it is not most preferred solution, because what PHP_TARGETS: -a b means is: build against b and not against a, and I don't care if it is not preferred, if it is obsolete, JUST DO IT, as long as it is possible.

comment:17 Changed 9 years ago by ciaranm

You still aren't understanding what's going on here. If presented with || ( a b ) and if a is masked and b isn't, and if there are no other relevant factors, then b will be selected. In the situation you are discussing, a is being selected instead, which means there are other factors too. The most likely other factors are an extra dependency forcing selection of a regardless, or the options you're passing to cave resolve forcing other slots to be considered too.

comment:18 Changed 9 years ago by ojezu

a is not masked, it requires PHP_TARGETS: php-5.2 which is not set. If there are other factors, then why aren't they listed in --explain suhosin , and how do I find them?

comment:19 Changed 9 years ago by ciaranm

A package whose [use] dependencies aren't met is 'masked'.

You find them by producing a minimal test case that doesn't involve PHP, use that to understand how
dependencies are decided, and then go from there and compare how the tree differs from your minimal test case, thus understanding the cause of your problems.

comment:20 Changed 9 years ago by ojezu

What goddamn factors?! Does cave make up factors for deciding on the fly and conceals them from the user? If there were any hidden, dark factors out of seventh pit of hell, why would they shift from blocking php-5.3 to php-5.2 after simple reordering of USE_PHP in eclass? Am I supposed to study source code of any disruptive program I am using to pinpoint some outter-dimensional factors? I will not give up this bug report, unless you stop repeating "you just do not get it" and show me those ghastly factors! For crying out loud, if a in || (a b) a resolves to false, --no-override-flags is set, b should not be reached? And if it will be reached won't it either turn out to be solution, or end up in Unsuitable candidates list? (wanna see output of such operation, there is nothing about discarding or even reaching b, I assure you). It just gets more and more ludicrous. Then maybe I should report a bug in paludis?
"paludis -i suhosin instead of reporting it is completely necessary to build suhosin for the first entry in USE_PHP list even if it is not set in PHP_TARGETS, just as cave does thanks to it's super-duper pro all-factor-seeing resolver, compiles suhosin against current PHP_TARGETS. Moreover, it succeeds and everything works just fine after install!".
Or another one
"cave while resolving takes into account some ludicrous, unknown to anybody factors"
The problem is, that after discarding a in || (a b) as uninstallable, cave does not even try to check if b is installable either with --no-override-flags on or off and not taking into account nature of a (is it USE flag, or PHP_TARGET or what?) . And that's all, no dark factor magic in here!

comment:21 Changed 9 years ago by ciaranm

Produce a minimal test case not involving PHP that demonstrates what you think is the problematic behaviour.

comment:22 Changed 9 years ago by ojezu

Here you go
not-suhosin-a uses flags not_php_target_5.2 not_php_target_5.3
not-suhosin-b uses PHP_TARGETS
with no not_php_target_5.2 flags or PHP_TARGETS: 5.2 not set cave resolve always returns with an error, presence of --no-override-flags changing only type of the error.

$ cat app-misc/not-suhosin-a/not-suhosin-a-0.1.ebuild

# Copyright 1999-2011 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $



IUSE="not_php_target_5.2 not_php_target_5.3"

RDEPEND=" || (

$ cat app-misc/not-suhosin-b/not-suhosin-b-0.1.ebuild

# Copyright 1999-2011 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $



IUSE="php_targets_php5-2 php_targets_php5-3"

RDEPEND=" || (

$ base64 senseless-test.tar.gz


comment:23 Changed 9 years ago by ciaranm

Your test case has the
( ) dependency backwards. It's not valid.

comment:24 Changed 9 years ago by ojezu

For crying out loud, we've already been through this! It is irrelevant! For the sake of example we can assume 5.2 is better, stronger, preferred or whatever! The problem is, that even with --no-override-flags cave never, never checks the second expression, no matter the nature of it. That's the bug and what is name of the flag in the second expression is not important, you can make it whatever you want! If you are out of such brilliant ideas, can we just reopen it and leave for someone to fix it, please? I had already enough of this pointless talk, I just wanted cave to treat PHP_TARGETS with any sense.

comment:25 Changed 9 years ago by ciaranm

Best leftmost. If you don't have that, there's no guarantee that
( ) dependencies will do the right thing. If you do have that, and then you encounter problems, *then* there's something to discuss. Until then, stop wasting everyone's time.
Note: See TracTickets for help on using tickets.