graphics/xpdf4: Cleans-up & improvements

[0mp]

Summary

graphics/xpdf4: Clean-ups & improvements

- Lint with portlint, portfmt, and portclippy.
- Add libpaper to LIB_DEPENDS and remove PAPER option. The PAPER option was not
  working for some time now (libpaper support was effectively always on
  regardless whether the PAPER option was set or not). Also, remove the patch
  that was supposed to add this functionality.
- Add pkg-message to SUB_FILES as there is a reference to LOCALBASE and PREFIX
  that should be patched dynamically and not hardcoded.
- Remove TYPE1 option as it was only adding a runtime dependency that is
  already present in RUN_DEPENDS anyway.
- Install GUI-specific files in a dedicated post-install target (this way we
  avoid some warning messages suggesting that we better set
  USES=desktop-file-utils)
- Regenerate patches with makepatch.
- Change the value of the Name key in the desktop file to "Xpdf".
- Install an icon so that it shows up in applications like
  misc/xfce4-appfinder.
- Remove PRINT_LDFLAGS as it is already covered by USES=localbase:ldflags.
- Set GUI_LIB_DEPENDS=libfontconfig.so:x11-fonts/fontconfig as suggested
  by the ports QA

[cy]

This is a lot of change for one commit and will confuse or at the very least cause people who review commit logs a lot of work and pain following what was just committed. Can I request you break this massive revision into smaller functional revisions, please? This is something I learned when I was added a src commit bit.

If you think this is too difficult, I do this all the time. As to how I do this, I use git to make multiple commits to my tree, either testing or not between git commits. The important one is when I push it up to ports (or src) using git svn dcommit -- I use svn for only really simple commits that need to be done in a hurry to fix some immediate breakage.

I would start by running portlint, committing a "make portlint happy" commit, then the libpaper commit.

I would never approve a makepatch commit to recreate patches. It is unnecessary churn. This needs to be removed. If one must to clean up patches, this must be performed in a separate commit, but not part of some jumbo revision. Please remove this from any revision.

We cannot do multiple changes in one massive commit.

graphics/xpdf4/files/patch-cmake-config.txt

67

This probably does not work because the port's ./configure detects an already installed libpaper. Making it an absolute dependency does make sense. This should be a separate commit. See my general comments about this revision.

[mat]

In D22279#488628, @cy wrote:

I would start by running portlint, committing a "make portlint happy" commit, then the libpaper commit.

Please do not "make portlint happy" portlint rarely gets it right. Please read the appropriate chapter about the order into which things go in a Makefile.

[0mp]

In D22279#488628, @cy wrote:

This is a lot of change for one commit and will confuse or at the very least cause people who review commit logs a lot of work and pain following what was just committed. Can I request you break this massive revision into smaller functional revisions, please? This is something I learned when I was added a src commit bit.

If you think this is too difficult, I do this all the time. As to how I do this, I use git to make multiple commits to my tree, either testing or not between git commits. The important one is when I push it up to ports (or src) using git svn dcommit -- I use svn for only really simple commits that need to be done in a hurry to fix some immediate breakage.

I would start by running portlint, committing a "make portlint happy" commit, then the libpaper commit.

I would never approve a makepatch commit to recreate patches. It is unnecessary churn. This needs to be removed. If one must to clean up patches, this must be performed in a separate commit, but not part of some jumbo revision. Please remove this from any revision.

We cannot do multiple changes in one massive commit.

Sure, that's the corrent thing to do.

I'll try to resubmit this patch in smaller chunks. Thanks a lot for your time!

[cy]

Just a hint at what I do, both on src and ports, is create a git branch, commit to it, then submit the revision here (because some people like to see the full picture). When the revision is reviewed, I rebase my git branch, git fetch && git svn rebase in master, merge my branch back into master, and finally git svn dcommit to push my changes back to svn.

The nice thing about this is that I can recommit my git commits in my working branch as people make comments or suggestions using git rebase -i and git diff the batch again, uploading it here. It saves a lot of work and keeps the repo history relatively clean.