Special regex characters are not escaped in path depspecs

[barracuda156]

--->  Computing dependencies for transmission-x11..
Error: Can't install gtk3 because conflicting ports are active: gtk3-devel

Same with other dependents of GTK3.

[ryandesign (Ryan Carsten Schmidt)]

In 722a3eb3a48203034034ec2bbab100638187d242/macports-ports (master):

amttools: Fix gtk3 dependency

See: #69585

[ryandesign (Ryan Carsten Schmidt)]

In e2ac810df736630218523cab231b46b1ac92a5e9/macports-ports (master):

nicotine-plus: Fix gtk3 dependency

See: #69585

[ryandesign (Ryan Carsten Schmidt)]

In 7687eb8889387a9840de250196f504a1a5390797/macports-ports (master):

stardict: Fix gtk3 dependency

See: #69585

[ryandesign (Ryan Carsten Schmidt)]

In ae17758e02d0de0e15f44c67852d6461ea454008/macports-ports (master):

gajim: Use path:-style dependencies

See: #69585

[ryandesign (Ryan Carsten Schmidt)]

In f4c5c116eb27f1e98968f18977916a4745f9b131/macports-ports (master):

geeqie: Use standard gtk3 dependency

See: #69585

[ryandesign (Ryan Carsten Schmidt)]

But none of those are in the recursive dependencies of transmission-x11 so they shouldn't have caused this problem, so I don't know. Can you attach a log? Or debug output? Maybe it will show which port is pulling in the dependency for gtk3 when you already have gtk3-devel.

[barracuda156]

Log from 10.6.8

[barracuda156]

Replying to ryandesign:

But none of those are in the recursive dependencies of transmission-x11 so they shouldn't have caused this problem, so I don't know. Can you attach a log? Or debug output? Maybe it will show which port is pulling in the dependency for gtk3 when you already have gtk3-devel.

I think the problem is still there, though I have no idea what causes it.

[barracuda156]

For sure the issue is unresolved. This is on 10.8.5:

10:~ svacchanda$ sudo port -v -n install rb33-gtk3
--->  Computing dependencies for rb33-gtk3..
Error: Can't install gtk3 because conflicting ports are active: gtk3-devel
Error: Follow https://guide.macports.org/#project.tickets if you believe there
is a bug.
Error: Processing of port rb33-gtk3 failed

[ryandesign (Ryan Carsten Schmidt)]

Does the file /opt/local/lib/pkgconfig/gtk+-3.0.pc exist?

[barracuda156]

Replying to ryandesign:

Does the file /opt/local/lib/pkgconfig/gtk+-3.0.pc exist?

It should. If it doesn't, that would explain why MacPorts is trying to install gtk3, and the investigation should focus on why that file doesn't exist.

Yes, it exists. Here is a clean Macports 2.9.3 on a standard 10.6.8 x86 (no custom ports, everything up-to-date):

10:~ svacchanda$ port -v installed gtk3-devel
The following ports are currently installed:
  gtk3-devel @3.24.41_0+x11 (active) requested_variants='-universal' platform='darwin 10' archs='x86_64' date='2024-04-07T07:18:54+0800'
10:~ svacchanda$ file /opt/local/lib/pkgconfig/gtk+-3.0.pc
/opt/local/lib/pkgconfig/gtk+-3.0.pc: ASCII text
10:~ svacchanda$ sudo port -v -n build transmission-x11 -universal
--->  Computing dependencies for transmission-x11.....................
Error: Can't install gtk3 because conflicting ports are active: gtk3-devel
Error: Follow https://guide.macports.org/#project.tickets if you believe there
is a bug.
Error: Processing of port transmission-x11 failed

Contents of .pc file:

prefix=/opt/local
exec_prefix=${prefix}
libdir=${prefix}/lib
includedir=${prefix}/include
targets=x11

gtk_binary_version=3.0.0
gtk_host=x86_64-darwin

Name: GTK+
Description: GTK+ Graphical UI Library
Version: 3.24.41
Requires: gdk-3.0 atk >= 2.35.1  cairo >= 1.14.0 cairo-gobject >= 1.14.0 gdk-pixbuf-2.0 >= 2.30.0 gio-2.0 >= 2.57.2
Requires.private: atk atk-bridge-2.0 epoxy >= 1.4 fribidi >= 0.19.7 pangoft2 gio-unix-2.0 >= 2.57.2
Libs: -L${libdir} -lgtk-3 
Cflags: -I${includedir}/gtk-3.0 

[barracuda156]

Same issue with gtk4-devel, path-style deps are not recognized:

36-231% sudo port -v upgrade pavucontrol
Updating dependencies for libsass @3.6.6_0
Warning: configured user/group macports does not exist, will build as root
--->  Computing dependencies for gtk4.
Error: Can't install gtk4 because conflicting ports are active: gtk4-devel
Error: Follow https://guide.macports.org/#project.tickets if you believe there
is a bug.

However gtkmm4 sets the dependency as a path-style.

[ryandesign (Ryan Carsten Schmidt)]

I am seeing this problem today while working on updating the synfig port:

Error: Can't install pango because conflicting ports are active: pango-devel

[ryandesign (Ryan Carsten Schmidt)]

In 617225aa193c4176d090d58bd7fccec89a689aef/macports-ports (master):

mlt: Allow other ports to satisfy dependencies

See: #69585

[ryandesign (Ryan Carsten Schmidt)]

In bb6c20bff3fd88d83560fa614eb8abdef3d3c2fd/macports-ports (master):

Fix gtk4 dependency

See: #69585

[ryandesign (Ryan Carsten Schmidt)]

Replying to barracuda156:

Same issue with gtk4-devel, path-style deps are not recognized:

However gtkmm4 sets the dependency as a path-style.

The gtk4 problem should be fixed. Ports that depended on gtk4 did so via a path that did not exist (lib/pkgconfig/gtk+-4.0.pc); I fixed it (to lib/pkgconfig/gtk4.pc).

The gtk3 problem remains and I see it on my machine as well, and the key lies in this line from the log:

Didn't find receipt, going to depspec regex for: gtk3

MacPorts takes the middle part of the depspec path:lib/pkgconfig/gtk+-3.0.pc:gtk3—lib/pkgconfig/gtk+-3.0.pc—and turns the last path component—gtk+-3.0.pc—into a regular expression. Specifically, it anchors it at the beginning (^) and end ($) but other than that it is copied directly into the regular expression without escaping (even though the MacPorts Guide says it's just a file path). This is significant for gtk2 and gtk3 since + is a special character in regular expressions. The path leading up to the last path component—e.g. lib/pkgconfig/—is not treated as a regular expression.

From portutil.tcl:

proc _pathtest {depspec {return_match 0}} {
    global prefix
    set depregex [lindex [split $depspec :] 1]

    # separate directory from regex
    set fullname $depregex

    regexp {^(.*)/(.*?)$} "$fullname" match search_path depregex

    if {[string index $search_path 0] ne "/"} {
        # Prepend prefix if not an absolute path
        set search_path "${prefix}/${search_path}"
    }

    set depregex \^$depregex\$

    return [_mportsearchpath $depregex $search_path 0 $return_match]
}

I would guess that this was not intentional and it was simply not considered that a filename that we might want to test would contain the + character. The problem would also occur for any filenames we might test that contain other special regex characters—like *, ^, $, [, ], {, }, (, )—but I don't think we've encountered those. . is also a special regex character meaning "any character" although that has not led to any problems.

One solution is to change all depspecs and escape all special regex characters. For example, the depspec path:lib/pkgconfig/gtk\\+-3\\.0\\.pc:gtk3 allows gtk3-devel to be used but this is ugly; we surely don't want to have to write that in every Portfile. The double backslash is needed because one level of escaping is interpreted by Tcl before it gets interpreted as a regex.

The better solution, I think, is to fix MacPorts base so that it escapes special characters in the depspec using quotemeta. That's implemented here: ​https://github.com/macports/macports-base/pull/337

[ryandesign (Ryan Carsten Schmidt)]

In 0a912220f32763a214d6eb5bc4cb7fcf389910cf/macports-ports (master):

Let other ports satisfy glibmm/pangomm deps

See: #69585

[ryandesign (Ryan Carsten Schmidt)]

In 8aa2503f5cd6d2e5212b498632b95e4682a80be2/macports-ports (master):

audacious-*: Fix gtk2 and gtk3 dependencies

See: #69585

[ryandesign (Ryan Carsten Schmidt)]

Replying to ryandesign:

I would guess that this was not intentional and it was simply not considered that a filename that we might want to test would contain the + character. The problem would also occur for any filenames we might test that contain other special regex characters—like *, ^, $, [, ], {, }, (, )—but I don't think we've encountered those.

It looks like one person previously discovered this feature and made use of it in the HandBrake and HandBrakeCLI ports by depending on {bin:python2(\.(4|5|6|7))?:python27}. Since allowing the build to use whatever python it finds is not particularly reproducible I would be ok with breaking this and requiring the HandBrake ports to change (for example to always depend on port:python27 and force the build system to use that python).

[jmroot (Joshua Root)]

Replying to ryandesign:

MacPorts takes the middle part of the depspec path:lib/pkgconfig/gtk+-3.0.pc:gtk3—lib/pkgconfig/gtk+-3.0.pc—and turns the last path component—gtk+-3.0.pc—into a regular expression. Specifically, it anchors it at the beginning (^) and end ($) but other than that it is copied directly into the regular expression without escaping (even though the MacPorts Guide says it's just a file path).

Note that the code has talked about "depspec regexes" for a very long time, see e.g. r2163. But I agree it's probably better to treat them as simple filenames.

[jmroot (Joshua Root)]

In e0c122648d02f89afd4c7fac2eef06e0b83f669d/macports-base (master):

Don't treat filenames in depspecs as regexes

Closes: ​https://github.com/macports/macports-base/pull/337
Closes: #69585