[Bug 191223] sysutils/hal: stage check reveals orphans

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=191223

--- Comment #2 from John Marino <marino at FreeBSD.org> ---
Here is the latest result (FreeBSD 10/AMD64/Poudriere 3.0.16)

===========================================================================
====> Running Q/A tests (stage-qa)
====> Checking for pkg-plist issues (check-plist)
===> Parsing plist
===> Checking for items in STAGEDIR missing from pkg-plist
Error: Orphaned: @unexec rmdir "/var/run/hald/hald-local" >/dev/null 2>&1 || :
Error: Orphaned: @unexec rmdir "/var/run/hald/hald-runner" >/dev/null 2>&1 || :
===> Checking for directories owned by MTREEs
===> Checking for directories handled by dependencies
Warning: Possibly owned by dependency: @dirrmtry share/PolicyKit/policy
Warning: Possibly owned by dependency: @dirrmtry share/PolicyKit
Warning: Possibly owned by dependency: @unexec rmdir "/var/lib" >/dev/null 2>&1
|| :
===> Checking for items in pkg-plist which are not in STAGEDIR
===> Error: Plist issues found.
*** Error code 1


I think the hald-local, hald-runner errors are false.  This is from the
pkg-plist:

@unexec rm -f /var/run/hald/hald.pid 2>/dev/null || true
@unexec rm -rf /var/run/hald/hald-local 2>/dev/null || true
@unexec rm -rf /var/run/hald/hald-runner 2>/dev/null || true
@unexec rmdir /var/run/hald 2>/dev/null || true
@unexec rmdir /var/cache/hald 2>/dev/null || true
@unexec rmdir /var/lib/hal 2>/dev/null || true
@unexec rmdir /var/lib 2>/dev/null || true


when I run "make makeplist", I get something like: 

@unexec rmdir /var/run/hald/hald-local 2>/dev/null || true
@unexec rmdir /var/run/hald/hald-runner 2>/dev/null || true
@unexec rmdir /var/run/hald 2>/dev/null || true
@unexec rmdir /var/cache/hald 2>/dev/null || true
@unexec rmdir /var/lib/hal 2>/dev/null || true
@unexec rmdir /var/lib 2>/dev/null || true

I think hal pkg-plist is technically correct, but the plist check is bad.  I
can think of some hacks to fool the check, but I am philosophically against
that.

What's the best way to address this?  And what about the "possibly owned"
errors?

-- 
You are receiving this mail because:
You are the assignee for the bug.