In sys-fs/btrfs-progs-0.19-r3 "acl" was optional. Now in 0.19.11 it isn't. This means that those of us, like me, who run ACL-free systems (no ACL, no PolicyKit, ACLs disabled in the kernel, etc.) must install the unwanted sys-apps/acl package, and potentially other ACL-related dependencies that might result in the future. Reproducible: Always Steps to Reproduce: 1. Install or upgrade to sys-fs/btrfs-progs-0.19.11 Actual Results: Unwanted sys-apps/acl package pulled in without option Expected Results: I should not need sys-apps/acl on a system in which ACLs have been disabled at kernel level. btrfs-progs should not require, and indeed did not previously require, ACLs in order to function. I do not want my systems tainted by ACLs. Please restore the ability to install btrfs-progs without requiring ACLs as a hard dependency. Reported here rather than upstream, since it's not exactly clear where "upstream" is (Red Hat, Oracle, Kernel.org?), nor where their appropriate out-of-distro bugzilla is.
Check here for various upstreams: https://btrfs.wiki.kernel.org/index.php/Btrfs_source_repositories In the past, with USE="-acl", you just wouldn't get a btrfs-convert binary. Now you get one unconditionally which in my opinion makes more sense (from Gentoo's POV). The installation of sys-apps/acl isn't a big deal, it's just a library needed by the program. See also: https://bugs.gentoo.org/show_bug.cgi?id=235328
Could Joe be persuaded to write a patch similar to that for bug 235328? I really do not want anything even remotely connected with ACLs anywhere near my systems, not even a support library. IMO this needs to be optional.
(In reply to comment #2) This is a silly request. sys-fs/acl is a very small, non-intrusive package. It has nothing to do with PolicyKit in any case.
If you can get a Makefile patch applied in the Chris Mason's git repo that would allow this to be easily toggled, I would be happy to add a use flag to the ebuild. I just don't want to make the ebuild more complicated to avoid a trivial dependency. The btrfs mailing list would be a good starting point.
What about adding USE='convert' (or something like that) that will determine to install or not btrfs-convert. And if one install btrfs-progs without this flag, than it'll require acl. >This is a silly request. sys-fs/acl is a very small, non-intrusive package. It's just useless in case of disabled acl in kernel. Why have useless software? And at the moment it's intusive, because to use btrfs one forced to install acl event if one don't need it.
(In reply to comment #5) Please see my requirements in comment 4.
Of cource, I saw it. Unfortunally, I don't able to write a patch for Makefile. It was my suggestion how to return status quo as in version 0.19-r3 without such unobvious and inelegant things like not installing btrfs-convert if USE=acl disabled. From my point of view USE=convert will make more sence in such case and will make possible to return to status quo.
I have no way to implement a convert use flag unless I make the ebuild significantly more complex by building targets individually. I'm not going to do that. Also, you are misusing the phrase "status quo".
When I say "status quo", I mean the situation before USE=acl was removed. And it is still like that in stable version sys-fs/btrfs-progs-0.19-r3. In it's ebuild I can see only two things about acl. This: if use acl; then emake CC="$(tc-getCC)" CFLAGS="${CFLAGS}" LDFLAGS="${LDFLAGS}" \ convert || die fi and this: if use acl; then dosbin btrfs-convert else ewarn "Note: btrfs-convert not built/installed (requires acl USE flag)" fi It doesn't look significantly complicated to me. Sorry if i don't understand something. I'm just user, not developer...
Some happy news for you: btrfs-convert has been made optional again as of btrfs-progs-3.19.
(In reply to tot-to from comment #9) > When I say "status quo", I mean the situation before USE=acl was removed. That's not what "status quo" means. From Wikipedia: > Status quo is a Latin phrase meaning the existing state of affairs... The phrase "return to the status quo" is like saying "change it back to the way it currently is". What you really meant is that you were unhappy with the status quo, and want to revert back to the previous state. Sorry to be pedantic, and I certainly mean no offense. Language misuse is a pet peeve of mine.
Mike, thanks for the good news! In the same Wikipedia article, I can see that the phrase "status quo" is a shortening of "in statu quo res erant ante bellum", meaning "in the state in which things were before the war". And it is the way I ment here. Of course, instead of a "war" I ment the dispute on acl flag. Is this change considered as temporary or we can rely on the existance of acl flag is the observable future?
