It makes no sense to complain about a symlink to /var.
Details
Diff Detail
- Lint
No Lint Coverage - Unit
No Test Coverage - Build Status
Buildable 10150 Build 10573: arc lint + arc unit
Event Timeline
I couldn't update this diff. It only offers to create a new revision. So I write in words:
Why do you write
${PREFIX}/*|${LOCALBASE}/*)
and not just
${PREFIX}/*) ?
Installation is done into ${PREFIX}, not ${LOCALBASE}.
Also, you can add another line to the warning clarifying what the user should do:
warn "Use a relative symlink pathname instead"
Can't parse that one.
Why do you write
${PREFIX}/*|${LOCALBASE}/*)
and not just
${PREFIX}/*) ?
Installation is done into ${PREFIX}, not ${LOCALBASE}.
Yes, but outside of a testing/QA environment, they are the same, and symlinks should be relative within.
Also, you can add another line to the warning clarifying what the user should do:
warn "Use a relative symlink pathname instead"
Right.
Yes, but outside of a testing/QA environment, they are the same, and symlinks should be relative within.
But only ${PREFIX} the location of the installation target. This warning logically pertains only to the installation target folder. So the check should be using only ${PREFIX}/*). It doesn't hurt to have the clause with both, it just doesn't have a particular meaning.
Of course it does, all symlinks within /usr/local must be relative. The fact that they point to a file within the package or one of its dependencies does not matter.
Look at, say, lang/gcc, all it does is provide 3 symlinks. Right now, it does the right thing, but if I only put PREFIX in there, and it was creating symlinks to LOCALBASE/bin/, it would not be reported as wrong, but it would be.