1 |
A few days ago i had an emerge -u world running, after having modified |
2 |
my USE variables. Portage aborted during the emerge of sys-libs/db-3.2.9 |
3 |
with the following error message: |
4 |
|
5 |
" |
6 |
Installing documentation: /var/tmp/portage/db-3.2.9/image//usr/docs ... |
7 |
/bin/cp: preserving permissions for |
8 |
`/var/tmp/portage/db-3.2.9/image//usr/docs/api_c': Invalid argument |
9 |
/bin/cp: preserving permissions for |
10 |
`/var/tmp/portage/db-3.2.9/image//usr/docs/api_cxx': Invalid argument |
11 |
[...] |
12 |
/bin/cp: preserving permissions for |
13 |
`/var/tmp/portage/db-3.2.9/image//usr/docs/utility': Invalid argument |
14 |
make: *** [install_docs] Error 1 |
15 |
|
16 |
!!! ERROR: The ebuild did not complete successfully. |
17 |
!!! Function src_install, Line 1, Exitcode 2 |
18 |
!!! (no error message) |
19 |
|
20 |
!!! emerge aborting on /usr/portage/sys-libs/db/db-3.2.9.ebuild . |
21 |
" |
22 |
|
23 |
I decided to take a look at that later, so I injected db and reran |
24 |
emerge -u world, but some time later evolution-1.0.7 failed with the |
25 |
same error message. btw, evolution is also using db (3.1.x I believe), |
26 |
so it apparently had something to do with those db ebuilds. |
27 |
|
28 |
After checking the Makefile at |
29 |
/var/tmp/portage/db-3.2.9/work/db-3.2.9/build_unix/Makefile I found out, |
30 |
that cp was being run with the -pr options. |
31 |
|
32 |
" |
33 |
install_docs: |
34 |
@echo "Installing documentation: $(docdir) ..." |
35 |
@test -d $(docdir) || \ |
36 |
($(mkdir) -p $(docdir) && $(chmod) $(dmode) $(docdir)) |
37 |
@cd $(docdir) && $(rm) -rf * |
38 |
@cd $(srcdir)/docs && $(cp) -pr * $(docdir)/ |
39 |
" |
40 |
|
41 |
After playing around with cp on my ACL enabled XFS filesystem I figured |
42 |
out, that I always get an Invalid argument error message, when I use cp |
43 |
with both the -p/--preserve and -r/--recursive options AND there really |
44 |
are subdirectories to be copied. Apart from that there was also this + |
45 |
after the permission mask of most files in the output of ls -l, which |
46 |
wasn't there before. Both happened only on my ACL enabled XFS filesystem |
47 |
and it seemed both had to do with the acl flag I had enabled. The acl |
48 |
manpage explained the situation: |
49 |
|
50 |
" |
51 |
CHANGES TO THE FILE UTILITIES |
52 |
On a system that supports ACLs, the file utilities ls(1), cp(1) |
53 |
and mv(1) change their behavior in the following ways: |
54 |
|
55 |
- For files that have a default ACL or an access ACL that |
56 |
contains more than the three required ACL entries, the ls(1) |
57 |
utility in the long form produced by ls -l displays a plus sign (+) |
58 |
after the permission string. |
59 |
|
60 |
- If the -p flag is specified, the cp(1) utility also preserves |
61 |
ACLs. If this is not possible, a warning is produced. |
62 |
|
63 |
- The mv(1) utility always preserves ACLs. If this is not |
64 |
possible, a warning is produced. |
65 |
|
66 |
The effect of the chmod(1) utility, and of the chmod(2) system |
67 |
call, on the access ACL is described in the section ``CORRESPONDENCE |
68 |
BETWEEN ACL ENTRIES AND FILE PERMISSION |
69 |
BITS''. |
70 |
" |
71 |
|
72 |
So it seems cp is unable to preserve the ACLs of recursively copied |
73 |
subdirectories, I don't know why. |
74 |
|
75 |
To sum it up - the "cp -pr <...>"-line in the db Makefile actualy does |
76 |
its job and the doc files are copied, but the warning cp produces on a |
77 |
system with ACL support causes Portage to abort, probably because of the |
78 |
non-zero exit status. In this context, ACL support means ACL enabled |
79 |
filesystem and fileutils compiled with the acl USE flag. |
80 |
|
81 |
The obvious workaround is to disable ACL either by remerging fileutils |
82 |
with an -acl USE flag or disabling ACL support in the kernel. I have |
83 |
temporarily remerged fileutils without ACL support, as it is the less |
84 |
major change until this issue can be resolved. My question is - can cp's |
85 |
apparent inability to preserve the ACLs of subdirectories be considered |
86 |
normal behaviour, or is this just a special case with my system (PII, |
87 |
GCC 2.95.3, kernel 2.4.19-crypto-r7, XFS 1.1)? Anyway, it might be a |
88 |
good idea to issue a warning about the acl flag on gentoo-announce or |
89 |
something. |
90 |
|
91 |
Georg N. Lipov |
92 |
P.S. Sorry for crossposting (Additional Comments Bug#4464/gentoo-dev), I |
93 |
considered this to be important. |