| 1 |
On 08/31/14 11:53, Rich Freeman wrote: |
| 2 |
> On Sun, Aug 31, 2014 at 11:08 AM, Anthony G. Basile <blueness@g.o> wrote: |
| 3 |
>> I do not understand why you oppose the standardization of VDB? |
| 4 |
>> |
| 5 |
> I think it would make sense to take a step back. |
| 6 |
> |
| 7 |
> What is it that you're actually after here? You want to be able to |
| 8 |
> determine information about packages that are installed. So, just |
| 9 |
> determine what information is required and define an API for providing |
| 10 |
> this information. I'd focus on software/script-friendliness first and |
| 11 |
> foremost - then people can write as many wrappers around it as they |
| 12 |
> like. |
| 13 |
|
| 14 |
I can agree with this except that's not how the Council originally |
| 15 |
phrased it. We were specifically speaking of VDB. Anyhow, I can change |
| 16 |
the language so it emphasizes the desired information suggesting that it |
| 17 |
may be obtained from VDB or otherwise as the PM wishes. |
| 18 |
|
| 19 |
> |
| 20 |
> How the package manager determines this information is not the |
| 21 |
> problem. If the package manager wants to run ldd against all the |
| 22 |
> binaries installed by the package and then recompile every ebuild in |
| 23 |
> the tree to see if there is a match, that is its own problem. |
| 24 |
|
| 25 |
This is kinda silly. The point is that all PM's generate certain |
| 26 |
information at build time and *should* cache it for later use. How they |
| 27 |
wish to cache it is up to them as long as they export it somehow. But |
| 28 |
if you get rid of the caching, then you drop one of the requirements |
| 29 |
we're seeking from the PM in this GLEP --- efficient lookup of |
| 30 |
information which is expensive to regenerate. |
| 31 |
|
| 32 |
Moving past NEEDED.ELF.2, take a look at gentoolkit. It also make use |
| 33 |
of portage's VDB in "class KeywordAnalyser: def __init__(...)" in |
| 34 |
enalyze/lib.py. So asking a very simple question like `list all files |
| 35 |
that belong to sys-apps/coreutils` draws from VDB cache. The equivalent |
| 36 |
of what you're suggesting is that the PM be allowed to recompile the |
| 37 |
package each time to answer that question. That's silly. |
| 38 |
|
| 39 |
How the caching is done is up to the PM, but what information needs to |
| 40 |
be cached to avoid expensive regeneration is not. It should be |
| 41 |
specified in the GLEP. |
| 42 |
|
| 43 |
> |
| 44 |
> Just focus on the interface, and trust those implementing the package |
| 45 |
> manager to do it in a competent fashion. If they don't then users |
| 46 |
> probably won't use the package manager if they care about those |
| 47 |
> features. Or maybe users care more about a few kilobytes of indexes |
| 48 |
> and would prefer that the package manager not store information which |
| 49 |
> it could re-derive, and that is perfectly fine as well. |
| 50 |
> |
| 51 |
> And yes, I realize we're talking about how to accomplish something |
| 52 |
> before we've decided whether to accomplish it. I think that for any |
| 53 |
> reasonable decision to be made about the latter it doesn't hurt to |
| 54 |
> have at least some sense of what the former is going to look like, |
| 55 |
> though not necessarily the detail of a full specification. It |
| 56 |
> wouldn't hurt to point out use cases too. This is a GLEP, so nobody |
| 57 |
> has to do anything unless the Council approves it... |
| 58 |
> |
| 59 |
> -- |
| 60 |
> Rich |
| 61 |
> |
| 62 |
|
| 63 |
|
| 64 |
|
| 65 |
-- |
| 66 |
Anthony G. Basile, Ph.D. |
| 67 |
Gentoo Linux Developer [Hardened] |
| 68 |
E-Mail : blueness@g.o |
| 69 |
GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA |
| 70 |
GnuPG ID : F52D4BBA |
Archives