Hello, It would seem that our official handbook instructions added --xattrs to the tar unpack command some time ago. This is good as it will allow us to use filecaps and such on system packages. However, our official install media currently do not enable xattr support on app-arch/tar. When --xattrs is passed, it does still unpack, but shows a warning on the terminal "tar: XATTR support is not available" which is a bit scary for new users. I'm not sure if the best course of action would be to enable it in the installcd package.use, or IUSE="+xattr" on tar ebuilds, or a more wide reaching profile change. Thanks!
Two possible fixes: force tar to build with the xattr flag for livecd builds just add +xattr to the tar ebuild and call it a day I would lean towards just making xattr default on tar, but I'm curious if base-system is against that.
(In reply to Rick Farina (Zero_Chaos) from comment #1) > Two possible fixes: > > force tar to build with the xattr flag for livecd builds > > just add +xattr to the tar ebuild and call it a day > > > I would lean towards just making xattr default on tar, but I'm curious if > base-system is against that. The kernel has to be able to support xattr on the filesystems where it will be used. This includes tmpfs. One problem would be on arches where the kernel is not that well supported. eg. coming to mind are older mips machines. i know kumba had issues when I hard coded --xattrs in catalyst. This just throws a warning but then we trade one "scary" warning for another. (I just live with the warnings on my mips32r2 boxes.) Another issue that comes to mind is what scripts would break? Scripts are often written with assumpitons about default behavior, so deviating could cause stuff to break out in the hinterlands and then people would have to laboriously trace back the origin to this changed default. So this doesn't argue against enable xattr support on app-arch/tar, it just limits it to the install media for amd64, x86 and possibly some others like arm. So my advice @releng is just build the install media with USE=xattr.
This breaks tar usage on those kernels when you simply install app-arch/tar with xattr support *available*?
(In reply to Anthony Basile from comment #2) > > The kernel has to be able to support xattr on the filesystems where it will > be used. This includes tmpfs. One problem would be on arches where the > kernel is not that well supported. eg. coming to mind are older mips > machines. i know kumba had issues when I hard coded --xattrs in catalyst. > This just throws a warning but then we trade one "scary" warning for > another. (I just live with the warnings on my mips32r2 boxes.) The problem was running an untar on an XFS filesystem that lacked XFS' xattr support. That caused....I think 'tar' itself to report "Operation not supported" once //per// file. ext3/ext4 filesystems only generate the error once and then silence themselves. Might be an XFS bug in the end, but I'm not sure. I strip out the xattr option in catalyst before I do runs on my MIPS machines now. See Bug #538654.
we should have USE=xattr in the default profile imo now
Should a new bug be opened about USE=xattr in default profile? Or how is the best way to get the ball rolling on this? Seems like a no-brainer to me, any anti- comments seem to be under the impression that having xattr support available on a tool like tar somehow makes that tar unusable for kernels/filesystems w/o support.
there's no need for another bug. we just announce it on the lists, see if anyone complains, and then enable it.
i've enabled this by default now: http://gitweb.gentoo.org/repo/gentoo.git/commit/?id=824d0647e08da946ec357e436038d795ac589fd4 was able to build stage1/2/3 and the attr/pyxattr packages were pulled in. this should start making its way out to release media.
I guess the advice on the kernel side is build xattr into XFS or hunt down the spamming bug I've encountered kernel-side?
(In reply to Joshua Kinard from comment #4) > The problem was running an untar on an XFS filesystem that lacked XFS' xattr > support. That caused....I think 'tar' itself to report "Operation not > supported" once //per// file. This reminds me [1]. I guess that setting xattrs also results in different errors on different filesystems while ext[234] fails silently. [1] https://github.com/systemd/systemd/issues/560#issuecomment-124010744
(In reply to Joshua Kinard from comment #9) it's up to you to make sure your system is coherent. that means enabling the kernel options to support USE=xattr, or disabling USE=xattr in your make.conf.
(In reply to SpanKY from comment #11) > (In reply to Joshua Kinard from comment #9) > > it's up to you to make sure your system is coherent. that means enabling > the kernel options to support USE=xattr, or disabling USE=xattr in your > make.conf. Okay, still need to get Catalyst fixed then to make xattr support optional/configurable. It's got the --xattr switch hardcoded right now, which is how I found the XFS issue in the first place.
(In reply to Joshua Kinard from comment #12) for your own personal/local builds, you're certainly free to make this into a USE flag. but for public releases, i think you're doing a disservice to users if you're producing stages that lack xattr info in them.
