Re: [gentoo-portage-dev] Dependency calculation turning on USE flags?

[Kent Fredric]

On 21 August 2011 08:10, Matt Turner <mattst88@g.o> 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