On Thursday 11 September 2008 04:55, Tero Roponen wrote:
quoted text
> this patch adds a preliminary support of extended attributes
> to tux3fuse.c. This is very lightly tested:
> 
> $ ls
> $ date > testfile.txt
> $ cat testfile.txt
> Thu Sep 11 14:48:00 EEST 2008
> $ getfattr -n hello testfile.txt
> testfile.txt: hello: No such attribute
> $ setfattr -n hello -v world testfile.txt
> $ getfattr -n hello testfile.txt
> # file: testfile.txt
> hello="world"
> 
> $ setfattr -n foo -v bar testfile.txt
> $ getfattr -n hello testfile.txt
> # file: testfile.txt
> hello="world"
> 
> $ getfattr -n foo testfile.txt
> # file: testfile.txt
> foo="bar"

Very nicely done!   I did not find the file /usr/include/attr/xattr.h
and I did find /usr/include/sys/xattr.h, so I barged in and changed the
include, and also changed ENOATTR to ENOENT to make it compile, then I
checked it in.

Of course this was wrong, as I knew I would find out by asking you.  I
noticed your test script uses setfattr and getfatter, which I do not
have on my system, but apt-cache search told me they are available in a
package called attr.  Good, I installed it, and it brought in the
libattr1 package.  But still no /usr/include/attr/xattr.h header!  But
installing libattr1-dev got me the header.

So it seems we have a new build dependency: libattr1-dev.  And we have
a way of compiling without it, the only bad effect of which is to return
ENOENT instead of ENOATTR, which does not seem like such a bad thing
considering you return EEXIST in your fuse patch, which wrongly implies
that the offending object is a file, just as ENOENT does.

Of course we can handle this nicely with pkg-config, right?  Well,

   pkg-config --cflags libattr1
   Package libattr1 was not found in the pkg-config search path.
   Perhaps you should add the directory containing `libattr1.pc'
   to the PKG_CONFIG_PATH environment variable
   No package 'libattr1' found 

Bummer.  Upstream for this package... or is it the package maintainer...
does not know or care about pkg-config.  Also, upstream for sys headers
does know know or care about xattrs, or my headers are out of date
which is a distinct possibility.

Anybody have suggestions on how to tidy this up, including where to send
patches upstream?

Until we have at least a pkg-config type solution I think we are better
off returning a slightly wrong error code than adding another build
dependency, thus steepening the pain curve for new Tux3 members
compiling for the first time.  I could be wrong about that, maybe we are
nowhere close to the pain threshold for dependencies yet.

Regards,

Daniel

_______________________________________________
Tux3 mailing list
Tux3@tux3.org
http://tux3.org/cgi-bin/mailman/listinfo/tux3