Hi all, > On Mar 17, 2024, at 5:09 PM, Bruno Haible <br...@clisp.org> wrote: > > Hi Gordon, > >>> It seems to me that many GNU packages (coreutils, emacs, gettext, sed, at >>> least) include <sys/xattr.h> only for the purpose of ACLs. >> >> That was why I was trying to make them work, yes. The libacl package >> requires them and is in turn taken advantage of if present by a great many >> other things. >> ... >> From what you say, it really might make more sense to build off of what the >> GNU tar and wget2 projects have already got -- it sounds like they're >> already further along than I got. > > So, what is your actual goal? > > Do you want to make the Linux libacl work on more platforms? Then Gnulib is > not involved, because > - Gnulib uses libacl, not the other way around, > - Gnulib already has specific code for each platform (excluding the new > ACLs in NetBSD 10).
While I was originally provoked to attempt work in this area because "why won't libacl compile?", I think that a more general solution is a better use of everyone's valuable time. This has got me thinking - a lot of stuff that just "uses libacl if it's present" really ought to be using the gnulib equivalent, which as you point out already covers those cases and many more besides. The trouble is, how do you persuade dozens of projects to try it the more general way? > Or do you want to make it easy for programs to store and read extended > attributes, like wget2 does? In this case a new Gnulib module is appropriate. I think this is _also_ needed. IMO, things like libacl ought to be built on top of truly _generalized_ extended-attribute access of the kind gnulib exists to facilitate, which is sort of what I was working towards (without having made that specific connection) until I found out the libacl people weren't interested. There is no reason I can think of that a package so many things rely on should be so limited by the OS services it makes use of... nor, of course, should so many things treat libacl as the only word in ACL access. I don't know; the whole thing seems a bit of a mess, really. >>> GNU tar needs variants with *at, which it declares in xattr-at.h. >> >> I'll be honest, I'd never even heard of those variants until now. > > Neither did I. But I did a code search > https://codesearch.debian.net/search?q=include+%3Csys%2Fxattr.h%3E&literal=1 > and looked at a few of the packages that use <sys/xattr.h>. > >>> GNU wget2 needs it in order to set >>> user.mime_type >>> user.charset >>> user.xdg.origin.url >>> user.xdg.referrer.url >>> user.last_modified >>> attributes, and has code for it on Linux, macOS, FreeBSD (the code for >>> FreeBSD being obviously buggy). >> >> "Obviously"? Why? > > Because in wget2-2.1.0/src/wget_xattr.h, in the FreeBSD case, the expansions > of the macros fsetxattr and fgetxattr are identical. ...Yikes! >>> Would you like to work on submitting a sys/xattr.h facility for Gnulib, >>> that >>> - covers all functions from glibc [1], >>> - works on Linux, Hurd, macOS, FreeBSD, NetBSD, Cygwin, Android ? >> >> Would I like to? Certainly. Would I know how? Unfortunately not. The only >> way I was able to get it to work on my Mac required overriding, and >> completely re-implementing the relevant parts of, the system xattr.h file; >> and I can't imagine it would be much different on those other platforms. How >> do you do something like that and have it work cross-platform? > > We have good techniques in Gnulib for doing this overriding > and re-implementing on specific platforms. You can take a look > at e.g. lib/truncate.c and m4/truncate.m4 to see how it's done > in simple cases. I am definitely interested in helping out with this. However, I am not blessed with a great deal of time to work on it in. I'll get back to you when I have something but it'll take me a while. >> As it is, I think even the C-language method I used might only reliably work >> for GCC, which not everyone uses. > > No worry about this point. The Gnulib techniques work with all C and C++ > compilers. Excellent! I see I have a great deal of reading to do. Thanks, Gordon S.
