On 21 August 2011 08:10, Matt Turner <matts...@gentoo.org> wrote: > > See https://bugs.gentoo.org/372513 >
^ tldr version for everyone else. This is due to the || condition in virtual/fortran || ( sys-devel/gcc[fortran,openmp?] sys-devel/gcc-apple[fortran,openmp?] dev-lang/ifc dev-lang/ekopath-bin ) Where gcc[fortran] takes precedence over ifc. > I wonder if there's some way we can manage this kind of situation? > Perhaps portage could print alternative dependencies for virtuals, > similar to the very helpful recent "The following keyword changes are > necessary to proceed:" addition. > > This usecases specifics aside, I'd welcome some sort of way to show that an "or" condition is occurring somewhere in the tree, but it'd have to be opt-in, instead of opt-out, as the potential for being very noisy is great ( you'll get a lot of noise if you hit virtual/perl-* for instance ). And likewise, I'd love to have "some way" to produce some sort of graph for alternative merge trees that may work if you toggle some variable, but the amount of complexity to do this I'd imagine is quite large, and could easily be computationally expensive. It would very likely need some limiting factor for how deep it did permutations at. [ebuild N ] sys-libs/libstdc++-v3-3.3.6 USE="(multilib) nls" 23,459 kB [ebuild N ] app-shells/tcsh-6.16 USE="perl -catalogs" 869 kB # app-shells/tcsh-6.16 => # perl? ( # dev-lang/perl # ) [ebuild N ] app-emulation/emul-linux-x86- compat-20100611 USE="(multilib)" 930 kB [ebuild N ] virtual/libstdc++-3.3 0 kB # virtual/libstdc++-3.3 => # || ( # =sys-libs/libstdc++-v3-bin-3.3* # =sys-libs/libstdc++-v3-3.3* # ) [ebuild N ] dev-lang/ifc-10.0.026-r1 40,378 kB # virtual/fortran-0 -openmp => # || ( # sys-devel/gcc +fortran # sys-devel/gcc-apple +fortran # dev-lang/ifc # dev-lang/ekopath-bin # ) # virtual/fortran-0 +openmp => # || ( # sys-devel/gcc +fortran # sys-devel/gcc-apple +fortran # dev-lang/ifc # dev-lang/ekopath-bin # ) # || ( # sys-devel/gcc +fortran +openmp # sys-devel/gcc-apple +fortran +openmp # dev-lang/ifc # dev-lang/ekopath-bin # ) [ebuild N ] virtual/fortran-0 USE="openmp" 0 kB [ebuild N F ] sci-chemistry/cns-1.2.1 USE="openmp" 31,981 kB Would be a sample output for depthlimit = 1 Note that in this example I have made a few omissions, some because I couldn't be bothered working out all the other ACCEPT_KEYWORDS stuff to mentally compute which of the above targets were actually possible to install and what ACCEPT_KEYWORDS permuations could be done, and others because they are for whatever reason "fixed dependencies", thus, showing only dependencies that user choices can impact. ie: app-emulation/emul-linux-x86-compat-20100611 has different dependencies depending on the multilib USE flag, but that useflag is profile mandated so its pointless to show to a user. Alternatively, you could let the user dictate what type of permutations to display/compute, ie: use-flag based permutations, keyword based permutations, mask-based permutations, ||() conditional OR based permutations, package-version/slot permutations etc. For "package version/slot" permutations, it would display every variation on package/slot ( ie: slots/versions that are not the "current" version ) that were installable, or installable with some permutation ( if the depth of permutation is large enough ), so that a user could see a path of installation they wanted and twist user masks to make it happen. Of course, this is all looking like harder and harder stuff to do ( programming is the gateway-drug for feature creep ) , but it would still be something nice to have on a theoretical magic computer that can do all computations in zero time. ΒΆΒΆ -- Kent perl -e "print substr( \"edrgmaM SPA NOcomil.ic\\@tfrken\", \$_ * 3, 3 ) for ( 9,8,0,7,1,6,5,4,3,2 );" http://kent-fredric.fox.geek.nz
