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