hier(7) has the following information: ... /compat/ normally a link to /usr/compat. If not, then the /usr/compat comments apply ... /usr/ contains the majority of user utilities and applications ... compat/ files needed to support binary compatibility with other operating systems, such as Linux In my environment /compat is indeed a symlink to /usr/compat. With 1.4.0.rc2 when doing pkg upgrade I get the following: [322/394] Upgrading linux-f10-flashplugin from 11.2r202.418_2 to 11.2r202.418_4... [322/394] Extracting linux-f10-flashplugin-11.2r202.418_4: 100% pkg: cannot rename //compat.8U70sa3Hubr4 to //compat: Not a directory [322/394] Deleting files for linux-f10-flashplugin-11.2r202.418_4: 100% pkg: unlinkat(compat): Not a directory zsh: exit 3 I must note that the (earlier version of the) package was installed when pkg was at 1.3.8. I see that the corresponding port has the following line in pkg-plist: %NO_ALSA%@dir %COMPATDIR% So, not sure if the problem is caused by the port or by pkg...
tijl@ proposed a fix in https://lists.freebsd.org/pipermail/svn-ports-head/2014-November/078099.html And I sorta did, too, in bug 195416 comment 7.
ports r374142 has similar regression of @dir /compat.
The root cause is probably @dir being not quite similar to how @dirrmtry was previously implemented. Before ports r358636 any errors (on stderr) were guaranteed to be silenced and ignored.
Assign to maintainer. I don't know which of www/linux-c6-flashplugin11 or www/linux-f10-flashplugin11 is meant, however.
Well, this PR needs its own patch attached. Otherwise it's just a statement there's a problem. If emulation@ didn't get the previous changes in 15 months, they probably aren't going to look at this either. Thus a committer outside of emulation is going to need everything prepared for him/her, especially when there are competing solutions to the problem.
I'll fix in pkg 1.4.0.rc3 thanks for reporting
Should be fixed in 1.4.0rc3