Gentoo Archives: gentoo-dev

From: "Anthony G. Basile" <blueness@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Update to the pax-utils.eclass
Date: Tue, 26 Aug 2014 22:21:16
Message-Id: 53FD08F1.9090509@gentoo.org
In Reply to: Re: [gentoo-dev] Update to the pax-utils.eclass by Alexander Tsoy
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

Replies

Subject Author
Re: [gentoo-dev] Update to the pax-utils.eclass "Rick \\\"Zero_Chaos\\\" Farina" <zerochaos@g.o>