On Fri, 2021-01-01 at 00:41:54 +0100, Andreas Henriksson wrote: > On Sat, Mar 14, 2020 at 08:01:16PM +0100, Guillem Jover wrote: > > Source: libarchive > > Source-Version: 3.4.0-2 > > Severity: important > > User: a...@packages.debian.org > > Usertags: libattr-drop-attr-xattr-header
> > This package uses the deprecated <attr/xattr.h> header (from libattr) > > instead of the one provided now by glibc <sys/xattr.h>. > [...] > > It looks like this is the only header used by this package from libattr, > [...] > > As Tobi already mentioned, libarchive checks for both attr/xattr.h and > sys/xattr.h .... revelant upstream commit that introduced this is: > https://github.com/libarchive/libarchive/commit/365a91def0c9c173b93643698d6ee4e8e0fc2746 > > I've verified in a chroot that libarchive still builds just fine even > when after `rm /usr/include/attr/xattr.h` has been done, the configure > output looks like this (only xattr parts included): > > ``` > # grep 'checking for.*xattr' /tmp/log > checking for attr/xattr.h... no > checking for sys/xattr.h... yes > checking for library containing setxattr... none required > checking for fgetxattr... yes > checking for flistxattr... yes > checking for fsetxattr... yes > checking for getxattr... yes > checking for lgetxattr... yes > checking for listxattr... yes > checking for llistxattr... yes > checking for lsetxattr... yes > ``` > > So it should be safe to drop the attr/xattr.h header from libattr1-dev > as far as libarchive is concerned. > > If I missed something please enlighten me, otherwise this bug report > should likely just be closed. As mentioned in the part that got trimmed, the libattr1-dev Build-Depends can be dropped, and even if it still gets pulled in by libacl1-dev (which currently does need it), it does not matter, as this package will just stop using the header when it finally disappears. Thanks, Guillem
