Bug 192879 - ports-mgmt/portlint: Ambiguous warnings and recommendations for paths outside of PREFIX
Summary: ports-mgmt/portlint: Ambiguous warnings and recommendations for paths outside...
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Some People
Assignee: Joe Marcus Clarke
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-08-21 06:49 UTC by Kubilay Kocak
Modified: 2014-10-26 18:44 UTC (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Kubilay Kocak freebsd_committer freebsd_triage 2014-08-21 06:49:11 UTC
------------------
@exec install -d -o root -g wheel -m 711 /var/spool/prelude
@unexec rmdir /var/spool/prelude 2>/dev/null || true
------------------

WARN: /mnt/home/koobs/repos/freebsd/ports/security/libprelude/pkg-plist: [96]: use "%D" or "%B" to specify prefix.
WARN: /mnt/home/koobs/repos/freebsd/ports/security/libprelude/pkg-plist: [96]: use "@dirrmtry" instead of "@unexec rmdir".

Changing it to:

------------------
@exec install -d -o root -g wheel -m 711 /var/spool/prelude
@dirrmtry /var/spool/prelude
------------------

WARN: /mnt/home/koobs/repos/freebsd/ports/security/libprelude/pkg-plist: [96]: Using @dirrmtry with absolute path will not work as you expected in most cases.  Use pkg-deinstall or @unexec rmdir ... if you want to remove a direc
tory such as /var/${PORTNAME}

An unambiguous case for handling & detecting directory removals for paths outside of prefix is needed, if we know what the current best-practice method is for doing that. (independent of pkg_* removal)
Comment 1 Kubilay Kocak freebsd_committer freebsd_triage 2014-08-21 06:55:11 UTC
As per IRC conversation with antoine@

16:50:45 antoine_ | either use
16:50:58 antoine_ | @exec install -d -o root -g wheel -m 711 /var/spool/prelude
                  | @unexec rmdir /var/spool/prelude 2>/dev/null || true
16:51:01 antoine_ | or
16:51:06 antoine_ | @exec install -d -o root -g wheel -m 711 /var/spool/prelude
                  | @dirrmtry /var/spool/prelude
16:51:39 antoine_ | i will put a commit hook killing everybody putting @cwd in plist
16:51:44 antoine_ | in a few days

portlint ought to work within these constraints
Comment 2 Kubilay Kocak freebsd_committer freebsd_triage 2014-08-21 07:08:01 UTC
More ambiguity fail, from Mk/Scripts/check-stagedir.sh 

===> Checking for items in STAGEDIR missing from pkg-plist
Error: Orphaned: @unexec rmdir "/var/spool/prelude" >/dev/null 2>&1 || :
Comment 3 John Marino freebsd_committer freebsd_triage 2014-08-21 09:20:17 UTC
over to marcus
Comment 4 Joe Marcus Clarke freebsd_committer freebsd_triage 2014-08-23 20:12:43 UTC
I'm not sure I clearly understand the ask.  Is it to check for @cwd and flag that as an error?
Comment 5 Antoine Brodin freebsd_committer freebsd_triage 2014-08-23 20:15:52 UTC
No,  as long as pkg_install is supported @cwd is legitimate.

@dirrmtry with full path should work fine with pkg_install since http://svnweb.freebsd.org/changeset/ports/358636
Comment 6 Bryan Drewery freebsd_committer freebsd_triage 2014-08-23 21:23:58 UTC
(In reply to Kubilay Kocak from comment #1)
> As per IRC conversation with antoine@
...
> 16:51:39 antoine_ | i will put a commit hook killing everybody putting @cwd
> in plist
> 16:51:44 antoine_ | in a few days

@cwd won't be needed for files but it will still be needed for @[un]exec and other keywords using %D. I had not been using @cwd in my ports at work and realized this. All keywords need to be checked for %D usage. For example, @shell and @sample depend on @cwd being right for %D. You would need to expand %D for all these uses in plists from the current @cwd.

Pkg is *not* safe without %D in execs. It will gladly run the command in the current directory you are in. So mkdir %D/dir -> mkdir dir. We could fix Pkg to cd into prefix but I still see people running 1.1.
Comment 7 Joe Marcus Clarke freebsd_committer freebsd_triage 2014-10-26 18:44:12 UTC
This has been fixed in 2.16.0.