Bug 276990 - security/gnupg: fix postexec/postunexec for new manpage path
Summary: security/gnupg: fix postexec/postunexec for new manpage path
Status: New
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Many People
Assignee: Adriaan de Groot
URL:
Keywords:
: 277288 (view as bug list)
Depends on:
Blocks:
 
Reported: 2024-02-11 19:45 UTC by Martin Neubauer
Modified: 2024-03-13 21:00 UTC (History)
4 users (show)

See Also:
bugzilla: maintainer-feedback? (adridg)


Attachments
pkg-plist fix (692 bytes, patch)
2024-02-11 19:45 UTC, Martin Neubauer
adridg: maintainer-approval+
Details | Diff
Updated patch file (2.58 KB, patch)
2024-03-01 17:15 UTC, Yasuhiro Kimura
yasu: maintainer-approval? (adridg)
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Neubauer 2024-02-11 19:45:33 UTC
Created attachment 248371 [details]
pkg-plist fix

On installation pkg creates a symlink for gpg.1.gz. The postexec/postunexec statements weren't adjusted when the manpage path was changed from $PREFIX/man to $PREFIX/share/man.
Comment 1 Adriaan de Groot freebsd_committer freebsd_triage 2024-02-11 21:35:06 UTC
Comment on attachment 248371 [details]
pkg-plist fix

Looks reasonable to me, but it'll be at least a week before I can land this.
Comment 2 Martin Neubauer 2024-02-12 13:00:05 UTC
(In reply to Adriaan de Groot from comment #1)
That should be alright. This doesn't seem to be an overly critical issue. I only noticed this by chance myself during a poudriere testport run for some completely unrelated changes.
Comment 3 Ale 2024-02-18 10:03:16 UTC
I think that the line
@postunexec [ -e %D/man/man1/gpg.1.gz ] || rm -f %D/man/man1/gpg.1.gz
should be kept, at least temporarily, to deal with the stale link (/usr/local/share/man/man1/gpg.1.gz) that will result upgrading from a previous version.
Comment 4 Muhammad Moinur Rahman freebsd_committer freebsd_triage 2024-02-25 06:28:38 UTC
*** Bug 277288 has been marked as a duplicate of this bug. ***
Comment 5 Yasuhiro Kimura freebsd_committer freebsd_triage 2024-03-01 17:15:44 UTC
Created attachment 248852 [details]
Updated patch file

Fix @postexec/@postunexec commands in pkg-plist.

* Chase move of man pages to share/man. ...(1)
* There is following description in the man page of pkg-script(5).

     In the particular case of an upgrade the scripts are run in the
     following order:
     1.   new pre-install
     2.   old pre-deinstall
     3.   replace binaries
     4.   new post-install

  It means @postunexec command isn't executed when package is upgraded
  with `pkg upgrade`. So replace @postunexec with @preunexec.
* Use '-L' primary of test(1) command to check if the file exists and
  it is symbolic link.
* Fix the logic to check if symbolic link exists and remove it if it
  does.
* As is explained above @postunexec command isn't executed when
  package is upgraded with `pkg upgrade`. As a result
  ${PREFIX}/man/man1/gpg.1.gz symlink isn't removed when current
  version of installed package is upgraded with `pkg upgrade`. So add
  @preexec command to remove the symlink if it exist.

PR:             276990
Proposed by:    Martin Neubauer (1)
Fixes:          e81d10224315.
Comment 6 Benjamin Jacobs 2024-03-13 21:00:35 UTC
(In reply to Yasuhiro Kimura from comment #5)

Just remark because I stumbled on the same issue,

Altough this makes sense to me.

  @comment Following line is necessary to remove stale ${PREFIX}/man/man1/gpg.1.gz symlink created by previous version
  @preexec if [ -L %D/man/man1/gpg.1.gz ]; then rm -f %D/man/man1/gpg.1.gz; fi

I don't quite understand why the logic needed to be changed as to remove and reinstall the link on each upgrade. The following would still have worked fine, wouldn't it?

  @postexec [ -e %D/bin/gpg ] || ln -sf gpg2 %D/bin/gpg
  @postunexec [ -e %D/bin/gpg ] || rm -f %D/bin/gpg
  @postexec [ -e %D/share/man/man1/gpg.1.gz ] || ln -sf gpg2.1.gz %D/share/man/man1/gpg.1.gz
  @postunexec [ -e %D/share/man/man1/gpg.1.gz ] || rm -f %D/share/man/man1/gpg.1.gz

To which I'd simply add (using the same conditional style):
  @postexec [ -L %D/man/man1/gpg.1.gz ] && rm -f %D/man/man1/gpg.1.gz

Or is the expectation that mandir may again change, and then it would be nicer to handle without having to carry some cleanup script for an undeterminated time? -- but yet here we are, so that argument seems weak to me :=)