Summary: | sys-apps/install-xattr should warn and not die if filesystem doesn't support extended attributes | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Richard Li <admin> |
Component: | [OLD] Core system | Assignee: | Anthony Basile <blueness> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | alexander.puchmayr, alexander, base-system, dev-portage, nikoli |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 427888 | ||
Attachments: | Add btrfs.* to default PORTAGE_XATTR_EXCLUDE. |
Description
Richard Li
2014-10-31 16:10:59 UTC
(In reply to Richard Li from comment #0) > I have a system with sys-apps/portage-2.2.12[xattr] and > sys-apps/install-xattr-0.3 installed. Today I found > app-emulation/virtualbox-modules-4.3.18 wouldn't install. The error message > was as follows: > > install-xattr: setxattr() failed: Operation not supported > !!! doins: > /usr/portage/app-emulation/virtualbox-modules/files/virtualbox.conf does not > exist > > > I looked into the error, and found the cause - something like this: > > 7362 > listxattr("/usr/portage/app-emulation/virtualbox-modules/files/virtualbox. > conf", NULL, 0) = 18 > 7362 > listxattr("/usr/portage/app-emulation/virtualbox-modules/files/virtualbox. > conf", "btrfs.compression\0", 18) = 18 > 7362 > getxattr("/usr/portage/app-emulation/virtualbox-modules/files/virtualbox. > conf", "btrfs.compression", 0x0, 0) = 4 > 7362 > getxattr("/usr/portage/app-emulation/virtualbox-modules/files/virtualbox. > conf", "btrfs.compression", "zlib", 4) = 4 > 7362 setxattr("/home/x/tmp//virtualbox.conf", "btrfs.compression", "zlib", > 4, 0) = -1 EOPNOTSUPP (Operation not supported) > 7362 write(2, "install-xattr: ", 15) = 15 > 7362 write(2, "setxattr() failed", 17) = 17 > > > > > Apparently, files under my /usr/portage have "btrfs.compression" set, and > some of my other filesystems (including /var/tmp/portage) are not btrfs. I > feel this should not be a hard error (at least when invoked by portage). > Probably install-xattr should provide an option to ignore such errors and > portage should use it. (Or just have install-xattr do so by default, if you > feel appropriate.) We can warn but not die on those errors, you're right its not that hard. But I'm not sure if that's the right course of action here. You have USE=xattr, which implies end-to-end xattr support. In other words, if a step along the chain of ebuild phases can't copy xattrs, and you are asking for xattrs, then the build should die. Also, are you should that btrfs compression can't support xattrs? Finally, there's more than just install-xattr that's a problem if you have USE=xattr. I'm cc-ing the portage team to see if they have an opinion on this. Does install-xattr support PORTAGE_XATTR_EXCLUDE? It's probably safe for us to add btrfs.* to the default PORTAGE_XATTR_EXCLUDE. It would be weird for ebuilds to set btrfs.* attributes inside $D. (In reply to Zac Medico from comment #2) > Does install-xattr support PORTAGE_XATTR_EXCLUDE? It's probably safe for us > to add btrfs.* to the default PORTAGE_XATTR_EXCLUDE. It would be weird for > ebuilds to set btrfs.* attributes inside $D. Yes, it does. portage_xattr_exclude = getenv("PORTAGE_XATTR_EXCLUDE"); if (portage_xattr_exclude == NULL) exclude = xstrdup("security.* trusted.* system.nfs4_acl"); else exclude = xstrdup(portage_xattr_exclude); Created attachment 388288 [details, diff]
Add btrfs.* to default PORTAGE_XATTR_EXCLUDE.
You can test if this helps by setting the following in make.conf:
PORTAGE_XATTR_EXCLUDE="btrfs.* ${PORTAGE_XATTR_EXCLUDE}"
(In reply to Zac Medico from comment #4) > Created attachment 388288 [details, diff] [details, diff] > Add btrfs.* to default PORTAGE_XATTR_EXCLUDE. This is in git now: https://github.com/gentoo/portage/commit/2fcdb5f36face97b4a8ce74831d287bd1dd9c2bf (In reply to Zac Medico from comment #5) > (In reply to Zac Medico from comment #4) > > Created attachment 388288 [details, diff] [details, diff] [details, diff] > > Add btrfs.* to default PORTAGE_XATTR_EXCLUDE. > > This is in git now: > > https://github.com/gentoo/portage/commit/ > 2fcdb5f36face97b4a8ce74831d287bd1dd9c2bf Should I also add "btrfs.*" to exclude in case PORTAGE_XATTR_EXCLUDE is empty, in the line: exclude = xstrdup("security.* trusted.* system.nfs4_acl"); (In reply to Anthony Basile from comment #6) > > Should I also add "btrfs.*" to exclude in case PORTAGE_XATTR_EXCLUDE is > empty, in the line: > > exclude = xstrdup("security.* trusted.* system.nfs4_acl"); Well, you should probably only provide defaults as a fallback if it's unset for some reason, and the fallback defaults should include btrfs.*. Now I realize that I forget to update the fallback defaults inside portage's movefile function. Maybe it's best to remove them, and treat unset PORTAGE_XATTR_EXCLUDE the same as an empty setting. (In reply to Zac Medico from comment #7) > (In reply to Anthony Basile from comment #6) > > > > Should I also add "btrfs.*" to exclude in case PORTAGE_XATTR_EXCLUDE is > > empty, in the line: > > > > exclude = xstrdup("security.* trusted.* system.nfs4_acl"); > > Well, you should probably only provide defaults as a fallback if it's unset > for some reason, and the fallback defaults should include btrfs.*. > > Now I realize that I forget to update the fallback defaults inside portage's > movefile function. Maybe it's best to remove them, and treat unset > PORTAGE_XATTR_EXCLUDE the same as an empty setting. Okay this will be out in the install-xattr 0.5 when i push it out. (In reply to Zac Medico from comment #7) > (In reply to Anthony Basile from comment #6) > > > > Should I also add "btrfs.*" to exclude in case PORTAGE_XATTR_EXCLUDE is > > empty, in the line: > > > > exclude = xstrdup("security.* trusted.* system.nfs4_acl"); > > Well, you should probably only provide defaults as a fallback if it's unset > for some reason, and the fallback defaults should include btrfs.*. > > Now I realize that I forget to update the fallback defaults inside portage's > movefile function. Maybe it's best to remove them, and treat unset > PORTAGE_XATTR_EXCLUDE the same as an empty setting. That sounds reasonable. If Anthony agrees, then do it please. (In reply to Brian Dolbec from comment #9) > (In reply to Zac Medico from comment #7) > > (In reply to Anthony Basile from comment #6) > > > > > > Should I also add "btrfs.*" to exclude in case PORTAGE_XATTR_EXCLUDE is > > > empty, in the line: > > > > > > exclude = xstrdup("security.* trusted.* system.nfs4_acl"); > > > > Well, you should probably only provide defaults as a fallback if it's unset > > for some reason, and the fallback defaults should include btrfs.*. > > > > Now I realize that I forget to update the fallback defaults inside portage's > > movefile function. Maybe it's best to remove them, and treat unset > > PORTAGE_XATTR_EXCLUDE the same as an empty setting. > > That sounds reasonable. If Anthony agrees, then do it please. Sounds good. I've posted a portage patch which removes the redundant defaults: http://thread.gmane.org/gmane.linux.gentoo.portage.devel/4739 *** Bug 533168 has been marked as a duplicate of this bug. *** (In reply to Zac Medico from comment #11) > I've posted a portage patch which removes the redundant defaults: > > http://thread.gmane.org/gmane.linux.gentoo.portage.devel/4739 This has landed in the latest stable portage. We're done. |