1 |
On 08/26/14 17:00, Alexander Tsoy wrote: |
2 |
> On Tue Aug 26 22:27:36 2014 Anthony G. Basile <blueness@g.o> wrote: |
3 |
>> Hi everyone, |
4 |
>> |
5 |
>> I plan to update the pax-utils.eclass because of bug #520198. Can |
6 |
>> people please review that bug and the latest suggestion for the eclass. |
7 |
>> Since I'm inverting some if and for blocks, a diff isn't as useful as |
8 |
>> just looking at the entire class. |
9 |
>> |
10 |
> What if scanelf will fail? Looks like pax-mark() will not report an error. |
11 |
|
12 |
scanelf doesn't return an error code on failing to pax mark. The paxctl |
13 |
and paxctl-ng do. eg. |
14 |
|
15 |
blueness@yellow /tmp $ rm -f abc |
16 |
blueness@yellow /tmp $ touch abc |
17 |
blueness@yellow /tmp $ scanelf -Xx abc >/dev/null ; echo $? |
18 |
0 |
19 |
|
20 |
If you want a more sophisticated example, remove the PT_PAX_FLAGS |
21 |
program header from an elf and you get the same results. I don't think |
22 |
its wise to change the behavior of scanelf because its used in portage |
23 |
eg in constructing NEEDED.ELF.2. So its not clear what the unintended |
24 |
consequences would be if we did report an error here. vapier would be |
25 |
able to better address that. I just wrote the eclass following the |
26 |
current behaviour. |
27 |
|
28 |
> |
29 |
> And there are unused variables in pax-mark(): pt_fail* and xt_fail*. |
30 |
> |
31 |
|
32 |
Thanks for catching the cruft. |
33 |
|
34 |
|
35 |
-- |
36 |
Anthony G. Basile, Ph.D. |
37 |
Gentoo Linux Developer [Hardened] |
38 |
E-Mail : blueness@g.o |
39 |
GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA |
40 |
GnuPG ID : F52D4BBA |