graphviz, graphviz-devel: manpage symlink to symlink doesn't get recreated to compressed version

[ballapete (Peter "Pete" Dyballa)]

pete 311 /\ apropos something
makewhatis: /opt/local/share/man/man1/dot2gxl.1: No such file or directory
something: nothing appropriate

pete 314 /\ l /opt/local/share/man/man1/{dot,gv}*  
-r--r--r--  1 root  wheel   9794  6 Sep 11:59 /opt/local/share/man/man1/dot.1.gz
lrwxr-xr-x  1 root  wheel      8  6 Sep 11:59 /opt/local/share/man/man1/dot2gxl.1 -> gv2gxl.1        <====
lrwxr-xr-x  1 root  wheel     11 10 Jul 22:04 /opt/local/share/man/man1/dot2gxl.1.gz -> gv2gxl.1.gz  <====
-r--r--r--  1 root  wheel    772  6 Sep 11:59 /opt/local/share/man/man1/dotty.1.gz
lrwxr-xr-x  1 root  wheel     11  6 Sep 12:00 /opt/local/share/man/man1/gv2gml.1.gz -> gml2gv.1.gz
lrwxr-xr-x  1 root  wheel     11  6 Sep 12:00 /opt/local/share/man/man1/gv2gxl.1.gz -> gxl2gv.1.gz
-r--r--r--  1 root  wheel   1113  6 Sep 11:59 /opt/local/share/man/man1/gvcolor.1.gz
-r--r--r--  1 root  admin   3252  6 Mär  2020 /opt/local/share/man/man1/gvdir.1.gz
-r--r--r--  1 root  wheel   1528  6 Sep 11:59 /opt/local/share/man/man1/gvgen.1.gz
-r--r--r--  1 root  wheel   2376  6 Sep 11:59 /opt/local/share/man/man1/gvmap.1.gz
-r--r--r--  1 root  wheel   1209  6 Sep 11:59 /opt/local/share/man/man1/gvmap.sh.1.gz
-r--r--r--  1 root  wheel   1795  6 Sep 11:59 /opt/local/share/man/man1/gvpack.1.gz
-r--r--r--  1 root  wheel  12664  6 Sep 11:59 /opt/local/share/man/man1/gvpr.1.gz

The manual entry obviously has become a compressed file now. Seems to be a mistake in the package itself and not in Portfile.

[ryandesign (Ryan Carsten Schmidt)]

MacPorts base automatically compresses all ports' manpages after the destroot phase. It is also supposed to handle repointing symlinks to the compressed version as needed. In this specific case, that seems not to have happened, possibly because the symlink in question points to another symlink.

Replying to ballapete:

lrwxr-xr-x  1 root  wheel      8  6 Sep 11:59 /opt/local/share/man/man1/dot2gxl.1 -> gv2gxl.1        <====

This symlink was created by the port and now points nowhere because MacPorts base changed gv2gxl.1 to gv2gxl.1.gz.

lrwxr-xr-x  1 root  wheel     11 10 Jul 22:04 /opt/local/share/man/man1/dot2gxl.1.gz -> gv2gxl.1.gz  <====

Based on the different timestamp and the fact that I don't see this in the package, I assume you created this symlink. This is the symlink MacPorts base should have created.

[ryandesign (Ryan Carsten Schmidt)]

MacPorts uses a two-pass process to compress manpages. First, it traverses the man directory, (re)compressing any manpage files it finds, and adding any symlinks to a list. In the second pass, it processes each symlink from the list. If the symlink destination is not a .gz file, it checks whether the destination plus the .gz suffix exists. If so, it deletes the symlink and makes a new one pointing to the .gz file, and adds a .gz suffix to the name of the symlink as well if it didn't have one.

The problem arises when a chain of symlinks is used, depending on the order in which the symlinks are processed, which is whatever order readdir returns them in. Assuming that order is alphabetical, then in the case of graphviz, dot2gxl.1 is processed first. Its destination is gv2gxl.1, which is also a symlink but MacPorts doesn't check that. It checks if gv2gxl.1.gz exists, which at this point it does not, so it doesn't change dot2gxl.1. Later it processes gv2gxl.1 which points to gxl2gv.1, which was a real file until MacPorts replaced it with the compressed gxl2gv.1.gz in the first pass. It checks if gxl2gv.1.gz exists, which it does, so it deletes gv2gxl.1 and creates gv2gxl.1.gz pointing to gxl2gv.1.gz, breaking the dot2gxl.1 symlink.

The solution might be to rewrite this as a three-pass process. The first pass would add all manpage files to one list, and for each symlink would check if its destination exists and if so add the symlink and its destination to a second list. The second pass would (re)compress all manpage files from the first list. The third pass would repoint symlinks using the second list. By having the first pass only record information about the state of the directory without changing it, we avoid any problems of breaking chains of symlinks, regardless what order we're processing the files.

[ballapete (Peter "Pete" Dyballa)]

Replying to ryandesign:

Based on the different timestamp and the fact that I don't see this in the package, I assume you created this symlink. This is the symlink MacPorts base should have created.

Yes, that's likely! Makewhatis repeatedly reported faulty symlinks I corrected manually. Could be this is one of them.

[ryandesign (Ryan Carsten Schmidt)]

Replying to ryandesign:

The problem arises when a chain of symlinks is used, depending on the order in which the symlinks are processed, which is whatever order readdir returns them in.

In fact another problem occurs before this: MacPorts only repoints symlinks if they are pointing to a real file (file isfile), not a symlink.

​https://github.com/macports/macports-base/blob/master/src/port1.0/portdestroot.tcl#L274-L275

This rewrite works for me for graphviz-devel: ​https://github.com/macports/macports-base/pull/212

[mascguy (Christopher Nielsen)]

Peter, are you still seeing this issue with the latest version of graphviz-devel? (It was updated to 2.49.1 earlier today.)

[ballapete (Peter "Pete" Dyballa)]

Replying to mascguy:

I checked the regular edition graphviz @2.40.1_4+pangocairo+x11 and also graphviz-devel @2.49.1_0+pangocairo+x11. The incorrect symlinks I found earlier are gone. I also checked whether all manual entries recorded in the contents listing of both ports are correct, and they are. They all resolve fine.

[mascguy (Christopher Nielsen)]

Beautiful, glad this is finally fixed! Oh, and graphviz has also been updated to 2.49.1, to correspond with graphviz-devel. (In case you didn't see the update.)

[ballapete (Peter "Pete" Dyballa)]

Replying to mascguy: Just saw it! (Last selfupdate yesterday to sort out all dependencies, today the tests, after building and installing libGLU and freeglut, followed by another selfupdate.)

[ryandesign (Ryan Carsten Schmidt)]

Duplicate #64240 reports the problem still exists. As I said above, the behavior of MacPorts is currently not deterministic because it depends on the order in which readdir returns its results. This ticket should not be closed until base is fixed to behave deterministically and to handle chains of manpage symlinks. I proposed a patch to base to fix it, though the patch is not completely correct. (IIRC it did not consider the case where a port installs manpage symlinks to deeply placed files, such as manpages installed within a python version directory.)

[ryandesign (Ryan Carsten Schmidt)]

Has duplicate #64740.

[mohd-akram (Mohamed Akram)]

Any update on this?

[ballapete (Peter "Pete" Dyballa)]

Replying to mohd-akram:

Any update on this?

graphviz-devel 4.0 does not yet build on PPC Tiger: #65263.

[mascguy (Christopher Nielsen)]

Dropping ownership of ticket, since this will require a fix in MacPorts base. (Per Ryan's previous comments.)

[ballapete (Peter "Pete" Dyballa)]

Right now graphviz-devel @7.0.3_0+gdk_pixbuf+pangocairo+poppler+rsvg+x11 is installed. It still has this fault:

pete 234 /\ l -t /opt/local/share/man/man1 | more
total 20264
lrwxr-xr-x   1 root      admin       8  5 Dez 21:30 dot2gxl.1 -> gv2gxl.1

pete 237 /\ man dot2gxl
man: No such file or directory
Failed to open the message catalog man on the path NLSPATH=<none>

No manual entry for dot2gxl

[ryandesign (Ryan Carsten Schmidt)]

In 5d143a161e71de772631a547636fc172b8fbe7d5/macports-ports (master):

graphviz-devel: Update to 7.0.4

Work around MacPorts base bug with symlinks to symlinks to manpages.

See: #61288

[ballapete (Peter "Pete" Dyballa)]

On PPC Tiger, Mac OS X 10.4.11, the update has a flaw in configure:

checking for off64_t... no
checking for struct stat64... no
checking for ... no
checking for fcntl.h... yes
checking for search.h... yes

In configure we can find:

20011	ac_fn_c_check_type "$LINENO" "struct stat64" "ac_cv_type_struct_stat64" "$ac_includes_default"
20012	if test "x$ac_cv_type_struct_stat64" = xyes
20013	then :
20014	
20015	printf "%s\n" "#define HAVE_STRUCT_STAT64 1" >>confdefs.h
20016	
20017	
20018	fi
20019	ac_fn_c_check_type "$LINENO" "" "ac_cv_type_" "$ac_includes_default"
20020	if test "x$ac_cv_type_" = xyes
20021	then :
20022	
20023	printf "%s\n" "#define HAVE_ 1" >>confdefs.h
20024	
20025	
20026	fi

and in its config.log therefore:

configure:20019: checking for 
configure:20019: /opt/local/bin/gcc-mp-7 -c -pipe -Os -arch ppc -Wall -Wextra -Wmissing-include-dirs -Wswitch-default -Wfloat-equal -Wundef -Wshadow -Wpointer-arith -Wbad-function-cast -Wcast-qual -Wconversion -Wstrict-prototypes -Wmissing-prototypes -Wnested-externs -Wtrampolines -Wlogical-op -fno-common -Wall -isystem/opt/local/include/LegacySupport -I/opt/local/include -I/opt/local/include conftest.c >&5
conftest.c: In function 'main':
conftest.c:62:13: error: expected expression before ')' token
 if (sizeof ())
             ^
configure:20019: $? = 1
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "graphviz"
| #define PACKAGE_TARNAME "graphviz"
| #define PACKAGE_VERSION "7.0.4"
| #define PACKAGE_STRING "graphviz 7.0.4"
| #define PACKAGE_BUGREPORT "https://gitlab.com/graphviz/graphviz/-/issues"
| #define PACKAGE_URL ""
| #define GVPLUGIN_CONFIG_FILE "config6"
| #define GVPLUGIN_VERSION 6
| #define DARWIN 1
| #define DARWIN_DYLIB ""
| #define DEFAULT_FONTPATH "~/Library/Fonts:/Library/Fonts:/Network/Library/Fonts:/System/Library/Fonts"
| #define PATHSEPARATOR ":"
| #define DEFAULT_DPI 96
| #define BROWSER "open"
| #define YYTEXT_POINTER 1
| #define HAVE_STDIO_H 1
| #define HAVE_STDLIB_H 1
| #define HAVE_STRING_H 1
| #define HAVE_INTTYPES_H 1
| #define HAVE_STDINT_H 1
| #define HAVE_STRINGS_H 1
| #define HAVE_SYS_STAT_H 1
| #define HAVE_SYS_TYPES_H 1
| #define HAVE_UNISTD_H 1
| #define STDC_HEADERS 1
| #define HAVE_DLFCN_H 1
| #define LT_OBJDIR ".libs/"
| #define HAVE_CXX11 1
| /* end confdefs.h.  */
| #include <stddef.h>
| #ifdef HAVE_STDIO_H
| # include <stdio.h>
| #endif
| #ifdef HAVE_STDLIB_H
| # include <stdlib.h>
| #endif
| #ifdef HAVE_STRING_H
| # include <string.h>
| #endif
| #ifdef HAVE_INTTYPES_H
| # include <inttypes.h>
| #endif
| #ifdef HAVE_STDINT_H
| # include <stdint.h>
| #endif
| #ifdef HAVE_STRINGS_H
| # include <strings.h>
| #endif
| #ifdef HAVE_SYS_TYPES_H
| # include <sys/types.h>
| #endif
| #ifdef HAVE_SYS_STAT_H
| # include <sys/stat.h>
| #endif
| #ifdef HAVE_UNISTD_H
| # include <unistd.h>
| #endif
| int
| main (void)
| {
| if (sizeof ())
| 	 return 0;
|   ;
|   return 0;
| }
configure:20019: result: no

Some keyword to check for seems to be missing…

[ryandesign (Ryan Carsten Schmidt)]

Replying to ballapete:

On PPC Tiger, Mac OS X 10.4.11, the update has a flaw in configure:

That doesn't seem to have anything to do with this ticket; please file a new one or ideally discuss it with the developers of graphviz since I don't think we're doing anything unusual in the portfile to cause that problem.

[ballapete (Peter "Pete" Dyballa)]

The man pages are now correct, on Tiger and, more promimently, on Monterey. SO this ticket can be closed as well!

[ryandesign (Ryan Carsten Schmidt)]

The problem remains to be fixed in the graphviz port, and as I said in comment:13 the ticket should remain open until the base bug is fixed.

[ryandesign (Ryan Carsten Schmidt)]

In aa5ac15e68c8482b21899ac05ab6fa1b1cc989b1/macports-ports (master):

graphviz: Update to 7.0.6

Work around MacPorts base bug with symlinks to symlinks to manpages.

See: #61288

[ballapete (Peter "Pete" Dyballa)]

Now with graphviz @9.0.0 the symlinks seem to be OK and this ticket can be closed.