[gentoo-dev] Portage version resolution deficiencies

[Paul Smith]

Hi all; I posted a message about this problem a few weeks ago.  Since
then I've looked at the code and traced it through, and verified my
fears: Portage's dependency resolution method is only superficial.

Consider this situation:

    cat/all/all-1.ebuild:       DEPEND=" ~cat/first-1 ~cat/second-1 "

    cat/first/first-1.ebuild    DEPEND=" cat/second "

    cat/second/second-1.ebuild  DEPEND=""
    cat/second/second-2.ebuild  DEPEND=""

It's obvious that there is an acceptable way to install these packages
when someone runs "emerge cat/all":

    cat/second-1
    cat/first-1
    cat/all-1

Unfortunately, Portage will not handle this properly (IMO).  When you
ask it to "emerge all", one of two things will happen depending on the
order in which Portage decides to merge "first" and "second" (which is
essentially random: IIUC the DEPEND list of cat/all is stored in a hash
table).  However I believe both results are incorrect.

The first thing that may happen is the merge will go like this:

    cat/second-2
    cat/first-1
    cat/second-1
    cat/all-1

The second thing that may happen is this:

    cat/second-1
    cat/second-2
    cat/first-1
    cat/all-1

In the first case it's bad because first-1 is compiled against a newer
version of a package, then an older version is installed.  The second
case is bad because all-1 asked for second-1 to be installed but by the
time we get to building all-1, second-2 is what's installed.  Most
likely all-1 will fail to build.


Why does this happen?  It's because when Portage resolves dependencies
it keeps no memory about restrictions other than those in the immediate
parent.

In the first case above the process goes like this:

  want cat/all (no version restriction)
    > the best match is cat/all-1
    cat/all-1 wants cat/first-1
      > the best match is cat/first-1
      cat/first-1 wants cat/second (no version restriction)
        > the best match is cat/second-2
        cat/second-2 has no dependencies
      < install cat/second-2
    < install cat/first-1
    cat/all-1 wants cat/second-1
      > the best match is cat/second-1
    < install cat/second-1
  < install cat/all-1

In the second case, it goes like this:

  want cat/all (no version restriction)
    > the best match is cat/all-1
    cat/all-1 wants cat/second-1
      > the best match is cat/second-1
    < install cat/second-1
    cat/all-1 wants cat/first-1
      > the best match is cat/first-1
      cat/first-1 wants cat/second (no version restriction)
        > the best match is cat/second-2
        cat/second-2 has no dependencies
      < install cat/second-2
    < install cat/first-1
  < install cat/all-1

Note how in each case when Portage tries to find the best match it ONLY
examines the restrictions of the immediate predecessor.  There is
nothing in the database that marks various versions as being "out of
bounds" due to some other package previously considered (in this case,
cat/all-1).


Before I spend much time writing about possible solutions to this
problem (which I'm sure most everyone here could also see), is there any
consensus that this is a problem, and that it should be fixed?

Or, am I misunderstanding something or is this just the way Portage is
supposed to work and people are OK with it as-is?

-- 
-------------------------------------------------------------------------------
 Paul D. Smith <psmith@××××××××××××××.com>   HASMAT: HA Software Mthds & Tools
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
-------------------------------------------------------------------------------
   These are my opinions---Nortel Networks takes no responsibility for them.

--
gentoo-dev@g.o mailing list