[MacPorts] #59445: restore_ports.tcl script fails with the error "infinite loop" (deps bug)

[MacPorts]

#59445: restore_ports.tcl script fails with the error "infinite loop" (deps bug)
---------------------+--------------------
  Reporter:  JDLH    |      Owner:  (none)
      Type:  defect  |     Status:  new
  Priority:  Normal  |  Milestone:
 Component:  base    |    Version:
Resolution:          |   Keywords:
      Port:          |
---------------------+--------------------

Comment (by JDLH):

 Here is my diagnosis of the failure in `restore_ports.tcl`, and why I
 think it's due to a dependency cycle which the script can't handle.

 The message "we appear to be stuck" comes from line 135, within proc
 `sort_ports {portList}`. This occurs when an iteration through `$newList`,
 the list of ports needing installation,
 results in no new ports being moved from `$newList` to the
 `$operationList`
 of ports to be installed.

 I added some diagnostic code just after the line with the "we appear to be
 stuck" message:
 {{{
             ui_error "newList($oldLen) is:"
             foreach port $newList {
                 foreach {active name variants} $port break
                 set deps [list]
                                 foreach dep
 $port_deps(${name},${variants}) {
                                         set installed "-"
                                         if {[info exists
 port_installed($dep)]} {
                                                 set installed
 $port_installed($dep)
                                         }
                                         lappend deps [list $dep installed
 $installed]
                                 }
                 ui_error [list $name $variants $deps ]
             }
 }}}

 The result was a long list of ports which could not be added to the
 install list. Among them were:

 {{{
 ...
 Error: adwaita-icon-theme {} {{xz installed 1} {pkgconfig installed 1}
 {icon-naming-utils installed -} {autoconf installed 1} {automake installed
 1} {libtool installed 1} {gtk3 installed 1} {librsvg installed 0}}
 ...
 Error: librsvg {viewer +} {{xz installed 1} {pkgconfig installed 1} {rust
 installed 1} {cargo installed 1} {glib2 installed 1} {cairo installed 1}
 {pango installed 1} {libcroco installed 1} {libxml2 installed 1} {gdk-
 pixbuf2 installed 1} {vala installed 1} {gobject-introspection installed
 1} {gtk3 installed 1} {python27 installed 1} {adwaita-icon-theme installed
 0}}
 ...
 }}}

 This says that the script cannot add `adwaita-icon-theme` to the
 installation queue because it depends on `librsvg`, which is not able to
 join the queue, and that the script also cannot add `librsvg` to the
 queue, because it (supposedly) depends on `adwaita-icon-theme`, which is
 not able to join the queue. This is a dependency cycle. The script has no
 way of resolving this.

 I verified that the script is able to remove items successfully at line
 127.

 I verified which dependencies the script was gathering for `librsvg`, by
 changing the main invocation in the final line to read,
 {{{
 #@@@ install_ports $operationList
 ui_msg [list "deps of librsvg" [dependenciesForPort "librsvg" [list
 "viewer" "+"]]]
 }}}

 This gave me the output:
 {{{
 {deps of librsvg} {xz pkgconfig rust cargo glib2 cairo pango
 libcroco libxml2 gdk-pixbuf2 vala gobject-introspection gtk3
 python27 adwaita-icon-theme}
 }}}

 And, the mac ports system itself confirms that both `gtk3` and `adwaita-
 icon-theme` are ports which `librsvg` depends on:
 {{{
 % port rdeps librsvg +viewer
 The following ports are dependencies of librsvg @2.44.14_0+viewer:
   xz
 ...[many lines omitted]...
       urw-fonts
   gtk3
     atk
 ...[many lines omitted]...
     hicolor-icon-theme
   adwaita-icon-theme
     icon-naming-utils
       p5.28-xml-simple
         p5.28-xml-namespacesupport
         p5.28-xml-sax
           p5.28-xml-sax-base
         p5.28-xml-sax-expat
     librsvg
 }}}

 I no longer believe the problem is that the script gathers dependencies
 incorrectly. The problem is that the script appears unable to handle a
 dependency cycle, even though the underlying MacPorts system can.

 A next step is to look into modifying the `restore_ports.tcl` script so
 that it can handle dependency cycles. I suspect that if it could detect
 that port A depended at the top level on port B, and port B on port A,
 that it could add an operation to install both of them together to the
 `$operationList`, and maybe that would succeed.

-- 
Ticket URL: <https://trac.macports.org/ticket/59445#comment:1>
MacPorts <https://www.macports.org/>
Ports system for macOS