Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Repoint manpage symlinks that point to symlinks #212

Draft
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

ryandesign
Copy link
Contributor

MacPorts previously only fixed up manpage symlinks that pointed to real manpage files, but some ports install manpage symlinks that point to other symlinks that then point to real manpage files.

The old two-step method of first compressing all manpage files and then fixing up symlinks is replaced with a three-step process that first inventories the man directory, then compresses all manpages, then fixes up symlinks. This ensures that we have a complete and accurate inventory including what each symlink points to before we change anything.

Closes: https://trac.macports.org/ticket/61288


This works for me to fix graphviz-devel's dot2gxl.1 symlink but I should do more testing on other types of ports, such as python modules or other ports that install manpages in a nonstandard man directory and then symlink those into the standard man directory.

MacPorts previously only fixed up manpage symlinks that pointed to real
manpage files, but some ports install manpage symlinks that point to
other symlinks that then point to real manpage files.

The old two-step method of first compressing all manpage files and then
fixing up symlinks is replaced with a three-step process that first
inventories the man directory, then compresses all manpages, then fixes
up symlinks. This ensures that we have a complete and accurate inventory
including what each symlink points to before we change anything.

Closes: https://trac.macports.org/ticket/61288
@jmroot
Copy link
Member

jmroot commented Oct 19, 2020

Do we actually need to do this at all on OS versions capable of hfscompression?

@ryandesign
Copy link
Contributor Author

If we could rely on hfscompression being available, then you're right, we wouldn't need this. However hfscompression requires the user to install libarchive to use its version of tar; the version provided by the OS hasn't been recent enough. We can't know at the time that we package up the archives on the build servers whether the user has hfscompression enabled. So I think we should continue to gzip-compress manpages as we've been doing.

Another reason not to change it now is that some ports may rely on the existing behavior, assuming that the manpages will be gzipped.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

2 participants