| 1 |
On Sat, Sep 23, 2006 at 10:34:03AM -0400, Mike Frysinger wrote: |
| 2 |
> On Saturday 23 September 2006 10:24, Alin Nastac wrote: |
| 3 |
> > I see only libraries in NEEDED and it is probably generated |
| 4 |
> > automatically. There is no way for the automatic tools to discover the |
| 5 |
> > dependency between pptpd and ppp version. |
| 6 |
> |
| 7 |
> that gets back to ABI versus dynamic plugins ... we already know we'll need a |
| 8 |
> new DEPEND to track dlopen-ed plugins |
| 9 |
> |
| 10 |
> > Besides, even if I would have somehow /usr/lib/ppp/2.4.3 in NEEDED file |
| 11 |
> > of the pptpd, the amount of computation needed to discover which package |
| 12 |
> > offers such thing would be prohibitive. The reciprocal operation (find |
| 13 |
> > which packages use the old path before upgrade) would also be prohibitive. |
| 14 |
> |
| 15 |
> no it wouldnt ... when you merge a package, you record all the SONAME's it |
| 16 |
> provides: |
| 17 |
> scanelf -qRS "${D}" > SONAME |
| 18 |
> |
| 19 |
> in fact, running `scanelf -qlpRS` doesnt take that long on my machine |
| 20 |
|
| 21 |
Flush the cache... Makes a world of difference. Additionally, he is |
| 22 |
talking about what is *done* with that data after the fact, iow other |
| 23 |
words walking the entire vdb to find all affected pkgs. Can pretty |
| 24 |
much gurantee after a build that data isn't likely to be available |
| 25 |
(part of the reason portageq calls during building are slow). |
| 26 |
|
| 27 |
Could collapse that into a simple mapping, but that introduces |
| 28 |
backwards compatibility issues... |
| 29 |
|
| 30 |
~harring |
Archives