Gentoo Archives: gentoo-dev

From: "Anthony G. Basile" <blueness@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] RFC: GLEP 64: Standardize contents of VDB and establish and API for exporting this information.
Date: Sun, 31 Aug 2014 16:25:20
In Reply to: Re: [gentoo-dev] RFC: GLEP 64: Standardize contents of VDB and establish and API for exporting this information. by Rich Freeman
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.
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.
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.
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.
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/ 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.
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.
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 >
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


Subject Author
Re: [gentoo-dev] RFC: GLEP 64: Standardize contents of VDB and establish and API for exporting this information. Ciaran McCreesh <ciaran.mccreesh@××××××××××.com>