graphviz: Update to 14.0.4

[Dave-Allured]

Description

• Update graphviz 12.2.1 --> 14.0.4.
• Update gvedit patch file.
• Remove smyrna patch. Was obsoleted upstream.
• Switch to XZ format for source distfile.
• Closes https://trac.macports.org/ticket/72880

Type(s)

Tested on

Mac OS 15.5
Xcode 16.2
Command Line Tools 16.2.0

Tested "install graphviz" and "install gvedit".

Also tested on CI; OS 14, 15, 26.

Verification

Have you

• followed our Commit Message Guidelines?
• squashed and minimized your commits?
• checked that there aren't other open pull requests for the same change?
• referenced existing tickets on Trac with full URL in commit message?
• checked your Portfile with port lint?
• tried existing tests with sudo port test?
• tried a full install with sudo port -vst install port -s install?
• tested basic functionality of all binary files?
• tested basic functionality of two commands: dot and gvedit
• checked that the Portfile's most important variants haven't been broken?

[macportsbot]

Notifying maintainers:
@mascguy for port graphviz.
@ryandesign for port graphviz.

[Dave-Allured]

Upstream discussion of the gvedit patch:
https://forum.graphviz.org/t/gvedit-library-util-c-not-found/3231

[szhorvat]

Thanks for pushing this through! I use Graphviz directly, for mathematics work, not merely as a dependency of some documentation build pipeline or similar. I appreciate having up-to-date versions.

[reneeotten]

@ryandesign @mascguy any comments on this PR? It seems that the concern regarding building on 10.5 has been resolved upstream and thus that shouldn't prohibit updating the graphviz port any longer. If there is no response I will merge this PR by the end of the week.

[Dave-Allured]

Graphviz is what I call a "foundational" port, with about 200 dependent ports. Also, the upstream change log shows many breaking changes after the current MacPorts version, graphviz 12.2.1.

Therefore I think we need a migration strategy before merging this update. I can think of several strategies, all problematical. I am willing to work on this if someone can suggest an optimal strategy. Any advice, please?

I will switch to draft until we have something worked out.

[reneeotten]

@Dave-Allured in the future please work something out first before submitting a PR. The queue is supposed to be stuff that is ready-to-go...

[Dave-Allured]

@reneeotten Will do. This time I did not notice the dependencies problem until after I filed the PR.

[szhorvat]

Also, the upstream change log shows many breaking changes after the current MacPorts version, graphviz 12.2.1.

Aren't most of these using Graphviz in a trivial way, simply calling the executable (and not linking to the library)? If so, these breaking changes are not relevant for most dependencies.

This is a classic conflict between end-user use (direct use of Graphviz, usually scientific) and developer use (dependencies, but typically trivial uses for things such as diagrams included in auto-generated documentation). I'd hope to see better support for end-user usage, which is often ignored in the context of package managers like MacPorts. Unlike dependencies, end-users are unfortunately invisible, so are often ignored.

[Dave-Allured]

Aren't most of these using Graphviz in a trivial way, simply calling the executable (and not linking to the library)?

@szhorvat Good question! According to the ports website, there are only 45 library dependents. The other 140 are build or run dependents. Assume all of the latter are simply calling the command line. 27 of these 45 library dependents are subports or other weird cases that should be ignored. This leaves 18 unique ports at risk for build breakage. This is a more manageable number than my 200 initial guess. So should we update now, and fix possible breakage later?

Related, I intend to rev bump the library dependencies after merging this update. That will find build breakage.

Also, were there any relevant command line changes in Graphviz 13 or 14? How do we assess whether some of those 140 build or run dependents are also at risk for runtime breakage due to command line changes?

[szhorvat]

This leaves 18 unique ports at risk for build breakage

I can help test these if you can post a list of these 18.

Also, were there any relevant command line changes in Graphviz 13 or 14? How do we assess whether some of those 140 build or run dependents are also at risk for runtime breakage due to command line changes?

Based on the changelog and fairly limited graphviz experience (I don't fiddle much with command line parameters) I'd say the risk of issues is low.

So should we update now, and fix possible breakage later?

How about testing those 18, and if all is fine update and deal with further issues later?

[Dave-Allured]

I can help test these if you can post a list of these 18.

Thank you for the help and discussion. Lame of me to not test myself. But my real job is getting in the way this week. Here are the 18 unique dependents.

• Get library dependents only, as listed on the ports website.
• Exclude build and run dependents.
• Exclude subports, considered as duplicates.
• Exclude -devel ports and deleted ports.
• Reduce versioned names to base port names.

PothosFlow
cutter-rizin
gegl-0.3
gramps
graphviz-oldgui
itpp
kgraphviewer
monotone-viz
nip2
p5-graphviz
p5-graphviz2
p5-tk-graphviz
port-depgraph
py-pygraphviz
root5
root6
vala
webdot

How about testing those 18, and if all is fine update and deal with further issues later?

Seems like a good plan. Go for it. Thanks again.