| 1 |
On Thu, Aug 16, 2012 at 9:26 PM, Rich Freeman <rich0@g.o> wrote: |
| 2 |
> On Thu, Aug 16, 2012 at 4:05 PM, Michael Mol <mikemol@×××××.com> wrote: |
| 3 |
>> The limited-visibility build feature discussed a week or so ago would |
| 4 |
>> go a long way in detecting unexpressed build dependencies. |
| 5 |
> |
| 6 |
> I can't say that is a coincidence, but my intent would be to include |
| 7 |
> @system as implicit dependencies, at least until we change that policy |
| 8 |
> (though the morbidly curious could use that as a test in a tinderbox |
| 9 |
> to find packages in @system that are good candidates for removal). |
| 10 |
> |
| 11 |
> I haven't gotten to test it, but after studying sandbox it shouldn't |
| 12 |
> be hard to just hack together a manual test by removing read access to |
| 13 |
> root from the config files and adding in a bazillion files. That |
| 14 |
> should at least let me profile performance/etc. I'm not convinced |
| 15 |
> that there isn't room for improvement, but if it works well as-is then |
| 16 |
> automating this shouldn't be hard at all. If portage has the |
| 17 |
> dependency tree in RAM then you just need to dump all the edb listings |
| 18 |
> for those packages plus @system and feed those into sandbox. That |
| 19 |
> just requires reading a bunch of text files and no searching, so it |
| 20 |
> should be pretty quick. As far as I can tell the relevant calls to |
| 21 |
> check for read access are already being made in sandbox already, and |
| 22 |
> obviously they aren't taking forever. We just have to see if the |
| 23 |
> search gets slow if the access list has tens of thousands of entries |
| 24 |
> (if it does, that is just a simple matter of optimization, but being |
| 25 |
> in-RAM I can't see how tens of thousands of entries is going to slow |
| 26 |
> down a modern CPU even if it is just an unsorted list). |
| 27 |
|
| 28 |
Yeah, I presumed you'd have @system as a set of implicit dependencies. |
| 29 |
The obvious approaches would be to either temporarily remove a package |
| 30 |
from @system, tell the portage to ignore a package while doing limited |
| 31 |
visibility, or copy @system to a different, temporary set and remove |
| 32 |
things piecemeal from there. |
| 33 |
|
| 34 |
That last might make the most sense. "--implicit-dependencies --- |
| 35 |
defaults to @system. Additional instances append to the set of |
| 36 |
implicit dependencies. Use, e.g. -${ATOM} or -@system to override |
| 37 |
default include." |
| 38 |
|
| 39 |
-- |
| 40 |
:wq |
Archives