1 |
On Sun, Aug 31, 2014 at 11:08 AM, Anthony G. Basile <blueness@g.o> wrote: |
2 |
> |
3 |
> I do not understand why you oppose the standardization of VDB? |
4 |
> |
5 |
|
6 |
I think it would make sense to take a step back. |
7 |
|
8 |
What is it that you're actually after here? You want to be able to |
9 |
determine information about packages that are installed. So, just |
10 |
determine what information is required and define an API for providing |
11 |
this information. I'd focus on software/script-friendliness first and |
12 |
foremost - then people can write as many wrappers around it as they |
13 |
like. |
14 |
|
15 |
How the package manager determines this information is not the |
16 |
problem. If the package manager wants to run ldd against all the |
17 |
binaries installed by the package and then recompile every ebuild in |
18 |
the tree to see if there is a match, that is its own problem. |
19 |
|
20 |
Just focus on the interface, and trust those implementing the package |
21 |
manager to do it in a competent fashion. If they don't then users |
22 |
probably won't use the package manager if they care about those |
23 |
features. Or maybe users care more about a few kilobytes of indexes |
24 |
and would prefer that the package manager not store information which |
25 |
it could re-derive, and that is perfectly fine as well. |
26 |
|
27 |
And yes, I realize we're talking about how to accomplish something |
28 |
before we've decided whether to accomplish it. I think that for any |
29 |
reasonable decision to be made about the latter it doesn't hurt to |
30 |
have at least some sense of what the former is going to look like, |
31 |
though not necessarily the detail of a full specification. It |
32 |
wouldn't hurt to point out use cases too. This is a GLEP, so nobody |
33 |
has to do anything unless the Council approves it... |
34 |
|
35 |
-- |
36 |
Rich |