| 1 |
On 08/31/14 08:46, Ciaran McCreesh wrote: |
| 2 |
> On Sun, 31 Aug 2014 08:43:48 -0400 |
| 3 |
> "Anthony G. Basile" <blueness@g.o> wrote: |
| 4 |
>> What is specified in the GLEP is what information |
| 5 |
>> should be cached and that a clearly documented API be produced. |
| 6 |
> You are specifying the colour of the flowers on the shelf inside |
| 7 |
> the bikeshed before we've established whether we need to store bikes, |
| 8 |
> and if we do, whether we need a shed for them, and if we do, whether it |
| 9 |
> will have a shelf. |
| 10 |
> |
| 11 |
|
| 12 |
If I follow your analogy you're suggesting there's no need to export |
| 13 |
VDB. However, there is a need to follow linking both forwards and |
| 14 |
backwards. This is generated by portage and cached in NEEDED.ELF.2. On |
| 15 |
a PaX enabled kernel, we often have to migrate the PaX flags from |
| 16 |
libraries to *all* ELF executables that link against them --- this is |
| 17 |
similar to revdep-rebuild.py but for migrating PaX flags. This |
| 18 |
information takes ~5 minutes to be generated on a typical desktop |
| 19 |
system. However, it is just a *regeneration* of information already |
| 20 |
available in NEEDED.ELF.2. Using the latter from VDB takes only seconds |
| 21 |
by comparison. It is counterproductive not to make this information |
| 22 |
available. |
| 23 |
|
| 24 |
-- |
| 25 |
Anthony G. Basile, Ph.D. |
| 26 |
Gentoo Linux Developer [Hardened] |
| 27 |
E-Mail : blueness@g.o |
| 28 |
GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA |
| 29 |
GnuPG ID : F52D4BBA |
Archives