[gentoo-dev] db-3.x ebuilds broken by ACL support - Bug #4464

[gentoo-dev] db-3.x ebuilds broken by ACL support - Bug #4464

[Georg N. Lipov]

A few days ago i had an emerge -u world running, after having modified
my USE variables. Portage aborted during the emerge of sys-libs/db-3.2.9
with the following error message:

"
Installing documentation: /var/tmp/portage/db-3.2.9/image//usr/docs ...
/bin/cp: preserving permissions for
`/var/tmp/portage/db-3.2.9/image//usr/docs/api_c': Invalid argument
/bin/cp: preserving permissions for
`/var/tmp/portage/db-3.2.9/image//usr/docs/api_cxx': Invalid argument
[...]
/bin/cp: preserving permissions for
`/var/tmp/portage/db-3.2.9/image//usr/docs/utility': Invalid argument
make: *** [install_docs] Error 1

!!! ERROR: The ebuild did not complete successfully.
!!! Function src_install, Line 1, Exitcode 2
!!! (no error message)

!!! emerge aborting on  /usr/portage/sys-libs/db/db-3.2.9.ebuild .
"

I decided to take a look at that later, so I injected db and reran
emerge -u world, but some time later evolution-1.0.7 failed with the
same error message. btw, evolution is also using db (3.1.x I believe),
so it apparently had something to do with those db ebuilds.

After checking the Makefile at
/var/tmp/portage/db-3.2.9/work/db-3.2.9/build_unix/Makefile I found out,
that cp was being run with the -pr options.

"
install_docs:
        @echo "Installing documentation: $(docdir) ..."
        @test -d $(docdir) || \
            ($(mkdir) -p $(docdir) && $(chmod) $(dmode) $(docdir))
        @cd $(docdir) && $(rm) -rf *
        @cd $(srcdir)/docs && $(cp) -pr * $(docdir)/
"

After playing around with cp on my ACL enabled XFS filesystem I figured
out, that I always get an Invalid argument error message, when I use cp
with both the -p/--preserve and -r/--recursive options AND there really
are subdirectories to be copied. Apart from that there was also this +
after the permission mask of most files in the output of ls -l, which
wasn't there before. Both happened only on my ACL enabled XFS filesystem
and it seemed both had to do with the acl flag I had enabled. The acl
manpage explained the situation:

"
CHANGES TO THE FILE UTILITIES
       On  a system that supports ACLs, the file utilities ls(1), cp(1)
and mv(1) change their behavior in the following ways:

       -   For files that have a default ACL or an access ACL that 
contains  more  than  the  three  required  ACL entries, the ls(1)
utility in the long form produced by ls -l displays a plus sign (+)
after the permission string.

       -   If the -p flag is specified, the cp(1) utility also preserves
ACLs.  If this is not possible, a warning is produced.

       -   The mv(1) utility always preserves ACLs. If this is not
possible, a warning is produced.

       The  effect  of the chmod(1) utility, and of the chmod(2) system
call, on the access ACL is described in the section ``CORRESPONDENCE
BETWEEN ACL ENTRIES AND FILE PERMISSION
BITS''.
"

So it seems cp is unable to preserve the ACLs of recursively copied
subdirectories, I don't know why.

To sum it up - the "cp -pr <...>"-line in the db Makefile actualy does
its job and the doc files are copied, but the warning cp produces on a
system with ACL support causes Portage to abort, probably because of the
non-zero exit status. In this context, ACL support means ACL enabled
filesystem and fileutils compiled with the acl USE flag.

The obvious workaround is to disable ACL either by remerging fileutils
with an -acl USE flag or disabling ACL support in the kernel. I have
temporarily remerged fileutils without ACL support, as it is the less
major change until this issue can be resolved. My question is - can cp's
apparent inability to preserve the ACLs of subdirectories be considered
normal behaviour, or is this just a special case with my system (PII,
GCC 2.95.3, kernel 2.4.19-crypto-r7, XFS 1.1)? Anyway, it might be a
good idea to issue a warning about the acl flag on gentoo-announce or
something.

Georg N. Lipov
P.S. Sorry for crossposting (Additional Comments Bug#4464/gentoo-dev), I
considered this to be important.