< entee> whatsoever.. how do i chown a dir in a aur package .install file?.. < entee> can't.. the user to chown to gets added during post_install().. < entee> and adding users in PACKETBUILD seems the wrong place.. < entee> *PKGBUILD < AAAA> entee: pick a uid and set the ownership in the PKGBUILD < entee> AAAA: srsly is this the solution to it? what happens on uuid conflict with oter packets? < entee> or how to avoid them < entee> this seems to be a dirty hack.. < BBBB> entee, see the mariadb .install as an example https://projects.archlinux.org/svntogit/packages.git/tree/mariadb/trunk/mariadb.install < AAAA> those are your options, either pick a static uid or put up eith pacman's warnings < entee> BBBB, hmm.. that's a good staring point. thx < AAAA> entee: it uses a static uid like i suggested before... < entee> AAAA: i see, but what's the point of using a static uuid when they are never using the uuid (89) when packing stuff. See:PKGBUILD < AAAA> entee: i don't know, you'd have to ask the packager < entee> BBBB, but this does not solve my issue. Recap:on update users are getting a 'warning: directory ownership differs on ...' message for the directories i'm chown-ing in the post_install() < BBBB> entee, what is the directory that you are needing to change ownership for? < entee> BBBB, the working directory of the daemon < entee> BBBB, see: https://aur.archlinux.org/packages/teamspeak3-server/ < BBBB> entee, so it's an empty directory < entee> yes < BBBB> entee, so you can create it in the post_install instead same as mariadb < entee> BBBB, hmm.. yes I could but then it won't be tracked by pacman.. < BBBB> entee, I think you just have to go with one or the other. As another example the murmur package does it the way you have it (create in PKGBUILD, chown in post_install) https://projects.archlinux.org/svntogit/community.git/tree/trunk?h=packages/murmur < entee> BBBB, chown does not work anymore... < entee> BBBB, when you install murmur twice you'll get: warning: directory ownership differs on /var/lib/murmur/ < AAAA> entee: your only options for avoiding that warning are picking a static uid or not including the directory in the package < entee> BBBB, they added a check to pacman which might be a bit too restrictive. I now fixed it by adding the directory during post_install.. < AAAA> entee: why is it too restrictive? it's just a warning, the package is still installed just fine... < entee> AAAA: you don't want to see warnings when installing packets from communit.. < entee> AAAA: or at least I don't. < AAAA> entee: that doesn't mean the check is too restrictive, pacman expects the filesystem to match its database < entee> AAAA: but one can not pack packages anymore which add users to the system and chown stuff to it. because when building the packet you simply won't know the users uuid unless it's assigned in this wiki table. < AAAA> entee: that just means that somebody needs to come up with a better way to handle users and groups, not that pacman should ignore inconsistencies < entee> AAAA: or you could add all the directories on post_install which renders pacman rather usless.. that's what I'm doing atm. < entee> AAAA: i think there is no simple solution to this. And it's not an inconsistency: its simply an information not provided during packing which you'll never have at this moment in time, unless you standardize ids. < AAAA> entee: if a directory has one owner in the package and another owner on the filesystem, that is by definition an inconsistency < AAAA> entee: the problem might be solvable by using user/group names rather than ids < entee> AAAA: do tarballs support symbolic usernames? < AAAA> entee: yes < entee> AAAA, how? < AAAA> entee: what do you mean "how"? it's part of the tar format < entee> AAAA, how can I, only using tar: 1. pack file A owned by foo on system X in tar B 2. add user foo on system Y (different uuid from foo on X) 3. unpack B so that A belongs to user foo on system Y ? < AAAA> entee: you can't until pacman and makepkg support ownership by symbolic name rather than id < entee> AAAA, so do we have to file a feature request?.. < AAAA> entee: you can if you want, it's already on my todo list < entee> AAAA, what do you have on your todo list? filing or fixing? < AAAA> entee: fixing < entee> AAAA, k thx.