Graphviz update to v12.2.1

[nieder]

Updates libgraphviz238 to v12.2.1. This is the last release that can keep the same libN we are now using. Later releases (current tip is 14.0.2) bump the install_name for some or all dylibs.

• updated ruby to ruby32 and removed some of the hardcoding since current ruby.pc doesn't publish lots of inherited build depends anymore
• Better configure patch for flat_namespace problems with older dists
• make sure we use a consistent python3 during the build (still don't build the python bindings)
• One shared dylib liblab_gamut.1.dylib disappeared, but the release notes and the linked upstream bug indicate that this was never a public API and they stopped packaging it in v10.0.1.

Tested that ggobi and pygraphviz-py310 packages build successfully against this new version.

[dmacks]

Both variants build on my 26.0. Definitely good to upgrade ruby and have a stable python.

Those share/doc/graphviz files (see in-line comments) look like they are mostly docs about the front-end programs (as if they were section 1 manpages), so maybe they actually should be in the 'graphviz(-nox)' package (share/doc/%n)?

[dmacks]

(now that I realized it's in a branch where I can write, I can just work on it myself:)

Turns out the PDF generation wasn't deterministic (no BDep:groff), and groff:Depends:ghostscript which is a dep we intentionally disable here. Therefore, disable PDF generation.

All automatically installed doc files are now in the varianted DocFiles location (rather than unvarianted graphviz/ that could cause colliisions).

[nieder]

@dmacks any thoughts on moving the bindings to splitoffs ? Then their corresponding man3 pages would be in the binding splitoff and not in -shlibs where we might end up with collisions when libN changes.

[dmacks]

@dmacks any thoughts on moving the bindings to splitoffs ? Then their corresponding man3 pages would be in the binding splitoff and not in -shlibs where we might end up with collisions when libN changes.

Support. That could also allow us to put them in better locations, such as the tcl in the central tcl-libdirs. Already the bindings are not visible to some of the languages due to the buried --libdir. And also our lua is broken because it doesn't even look in %p libs at all.

Edit: that lua breakage is #1290

[nieder]

List of graphviz bindings. The table has whether they're currently installed in Fink and whether the default is to be on or off. There are many bindings that default to ON but we don't have/want them, so should explicitly disable them to be safe.

Binding	In Fink pkg	configure default
d	no	off
go	disabled	on
guile	yes	on
java	disabled	on
javascript	no	off
lua	yes	on
perl	$${\color{red}no}$$	on
php	$${\color{red}no}$$	on
python	disabled	on
python3	disabled	on
r	disabled	on
ruby	yes	on
sharp	$${\color{red}no}$$	on
swig	$${\color{green}yes}$$	on
tcl	yes	on

swig is required by guile, lua, ruby, and tcl bindings

[nieder]

Done with pushing the bindings to SplitOffs and trying to be deterministic about them. Plus with splitoffs, if something is not built, it'll be much easier to know when debbing fails.