[arch-dev-public] [signoff] fakeroot 1.8.10-2
This version fixes the fakeroot/acl/makepkg bug when using cp -a on directories. For details, see http://bugs.archlinux.org/task/8214#comment22826
On Jan 4, 2008 7:18 AM, Thomas Bächler <thomas@archlinux.org> wrote:
This version fixes the fakeroot/acl/makepkg bug when using cp -a on directories. For details, see http://bugs.archlinux.org/task/8214#comment22826
Wow, the fix doesn't include sweeping code changes and yet this bug has been around for a while. Where did this patch come from? Does upstream have it? -Dan
This version fixes the fakeroot/acl/makepkg bug when using cp -a on directories. For details, see http://bugs.archlinux.org/task/8214#comment22826
Wow, the fix doesn't include sweeping code changes and yet this bug has been around for a while. Where did this patch come from? Does upstream have it?
I took the time and wrote the patch, thus upstream does not have it. Actually, this patch is only a workaround: It makes it look like the underlying filesystem never supports ACLs when writing them (you can still read ACLs though). coreutils falls back to a function called chmod_or_fchmod in this case, which apparently uses either chmod or fchmod to set the mode, both of which are wrapped by fakeroot. It may not fix other broken tools, but I don't know about any other breakage. For us this is fine, as pacman packages (tarballs) should only contain normal Unix permissions (I doubt that tar has support for ACLs anyway) and most of our users don't even use ACLs. However, this does not extend the fakeroot environment to support ACLs, thus it is not a good thing for an upstream package: The patch would probably be rejected.
On Jan 4, 2008 11:12 AM, Thomas Bächler <thomas@archlinux.org> wrote:
This version fixes the fakeroot/acl/makepkg bug when using cp -a on directories. For details, see http://bugs.archlinux.org/task/8214#comment22826
Wow, the fix doesn't include sweeping code changes and yet this bug has been around for a while. Where did this patch come from? Does upstream have it?
I took the time and wrote the patch, thus upstream does not have it. Actually, this patch is only a workaround: It makes it look like the underlying filesystem never supports ACLs when writing them (you can still read ACLs though). coreutils falls back to a function called chmod_or_fchmod in this case, which apparently uses either chmod or fchmod to set the mode, both of which are wrapped by fakeroot. It may not fix other broken tools, but I don't know about any other breakage.
For us this is fine, as pacman packages (tarballs) should only contain normal Unix permissions (I doubt that tar has support for ACLs anyway) and most of our users don't even use ACLs. However, this does not extend the fakeroot environment to support ACLs, thus it is not a good thing for an upstream package: The patch would probably be rejected.
Well, wow, thanks a lot. This is great work. Do you happen to have a test case for me to test? Or should I just mount something with ACLs and compare to a package build without ACLs?
On Jan 4, 2008 11:16 AM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On Jan 4, 2008 11:12 AM, Thomas Bächler <thomas@archlinux.org> wrote:
This version fixes the fakeroot/acl/makepkg bug when using cp -a on directories. For details, see http://bugs.archlinux.org/task/8214#comment22826
Wow, the fix doesn't include sweeping code changes and yet this bug has been around for a while. Where did this patch come from? Does upstream have it?
I took the time and wrote the patch, thus upstream does not have it. Actually, this patch is only a workaround: It makes it look like the underlying filesystem never supports ACLs when writing them (you can still read ACLs though). coreutils falls back to a function called chmod_or_fchmod in this case, which apparently uses either chmod or fchmod to set the mode, both of which are wrapped by fakeroot. It may not fix other broken tools, but I don't know about any other breakage.
For us this is fine, as pacman packages (tarballs) should only contain normal Unix permissions (I doubt that tar has support for ACLs anyway) and most of our users don't even use ACLs. However, this does not extend the fakeroot environment to support ACLs, thus it is not a good thing for an upstream package: The patch would probably be rejected.
I feel like it is worth attaching to the Debian bug report to make a point. "Look, you've had this bug forever that everyone refuses to look at and I've made a patch that at least fixes/remedies *broken* behavior, even if it is not ideal." If they reject it they seem to be on a bit of a power trip. And well done on the patch.
Well, wow, thanks a lot. This is great work. Do you happen to have a test case for me to test? Or should I just mount something with ACLs and compare to a package build without ACLs?
I don't mount anything with ACLs, but I will be sure everything works without them (no regressions). I'll test and hopefully signoff later tonight. To anyone else- strace might be helpful here to test. -Dan
Aaron Griffin schrieb:
Well, wow, thanks a lot. This is great work. Do you happen to have a test case for me to test? Or should I just mount something with ACLs and compare to a package build without ACLs?
Any package that installs manpages to /usr/share/man will be fine (fakeroot, ntfs-3g). Or just use cp -a (or just cp -p) inside a PKGBUILD. It seemed fine here for the fakeroot built (I built fakeroot using the new fakeroot) and in my test case (cp -a a directory inside a fakeroot and permissions will be f*cked with the old version). If you feel like reading code you may tell me why cp -a copied files fine, but not directories. BTW, tmpfs uses ACLs by default.
On Jan 4, 2008 7:18 AM, Thomas Bächler <thomas@archlinux.org> wrote:
This version fixes the fakeroot/acl/makepkg bug when using cp -a on directories. For details, see http://bugs.archlinux.org/task/8214#comment22826
Signoff, i686, but did *not* test anything dealing with ACLs. However, I see no regressions anywhere else. -Dan
participants (3)
-
Aaron Griffin
-
Dan McGee
-
Thomas Bächler