| 1 |
On Thu, Aug 16, 2012 at 4:05 PM, Michael Mol <mikemol@×××××.com> wrote: |
| 2 |
> The limited-visibility build feature discussed a week or so ago would |
| 3 |
> go a long way in detecting unexpressed build dependencies. |
| 4 |
|
| 5 |
I can't say that is a coincidence, but my intent would be to include |
| 6 |
@system as implicit dependencies, at least until we change that policy |
| 7 |
(though the morbidly curious could use that as a test in a tinderbox |
| 8 |
to find packages in @system that are good candidates for removal). |
| 9 |
|
| 10 |
I haven't gotten to test it, but after studying sandbox it shouldn't |
| 11 |
be hard to just hack together a manual test by removing read access to |
| 12 |
root from the config files and adding in a bazillion files. That |
| 13 |
should at least let me profile performance/etc. I'm not convinced |
| 14 |
that there isn't room for improvement, but if it works well as-is then |
| 15 |
automating this shouldn't be hard at all. If portage has the |
| 16 |
dependency tree in RAM then you just need to dump all the edb listings |
| 17 |
for those packages plus @system and feed those into sandbox. That |
| 18 |
just requires reading a bunch of text files and no searching, so it |
| 19 |
should be pretty quick. As far as I can tell the relevant calls to |
| 20 |
check for read access are already being made in sandbox already, and |
| 21 |
obviously they aren't taking forever. We just have to see if the |
| 22 |
search gets slow if the access list has tens of thousands of entries |
| 23 |
(if it does, that is just a simple matter of optimization, but being |
| 24 |
in-RAM I can't see how tens of thousands of entries is going to slow |
| 25 |
down a modern CPU even if it is just an unsorted list). |
| 26 |
|
| 27 |
Rich |
Archives