[pacman-dev] Directory permission warnings

Andrew Gregory andrew.gregory.8 at gmail.com
Sat Jan 31 15:14:29 UTC 2015

On 01/31/15 at 11:56pm, Allan McRae wrote:
> It seems people are getting really confused with the directory
> permission warnings that makepkg prints when upgrading a package that
> changes some permissions in its install script.
> There are a few ways to deal with this:
> 1) some packages have a reserved user:group ids - these should be
> chmoded in the PKGBUILD rather than the install scriptlet.
> 2) We somehow flag those directories/files that will change permissions.
>  This will stop the directory permission warnings and -Qkk errors.
> 3) I opened a bug a couple of years ago:
> https://bugs.archlinux.org/task/30185 .  Most (all?) of the directory
> permission warnings are for directories owned by an individual package.
>  So we should just fix the permissions.  This will still leave -Qkk errors.
> Any other thoughts on this?
> A

For dynamically created users, which is the only reason install
scripts should be setting ownership, my preferred solution would be to
use symbolic names in the package.[1]  Pacman support should be
trivial, but I don't know of a *good* way to get the ownership
information into the package tarball at the moment.  We could hack
something together using libarchive, and, if everybody else agrees, we
might be able to get something similar to NetBSD mtree's -N switch
into bsdtar to do it more cleanly.[2]

That doesn't help the situation where a package changes ownership
between versions, though.  Manually changing directory ownership feels
a little wrong to me, but as long as we adjust NoUpgrade to allow
users to prevent it, I think it's acceptable.  I don't think using
a flag to suppress warnings is a good idea.  Incorrect ownership can
cause problems.  If the packager flags a directory that really does
need particular ownership the user wouldn't have any notice of the

[1] https://bugs.archlinux.org/task/43484
[2] http://netbsd.gw.com/cgi-bin/man-cgi/man?mtree+8+NetBSD-current


More information about the pacman-dev mailing list