1 |
On 09/06/14 10:04, Ciaran McCreesh wrote: |
2 |
> On Sat, 06 Sep 2014 09:51:58 -0400 |
3 |
> "Anthony G. Basile" <blueness@g.o> wrote: |
4 |
>>> Paludis doesn't do this (and historically, Portage didn't either). |
5 |
>>> We store USE etc. This is useful because it allows us to detect when |
6 |
>>> people have been mucking around with DEPEND and the like. |
7 |
>> This was a suggestion from mgorny and I trust his opinion on the |
8 |
>> matter. It does make sense to have metadata catche which is |
9 |
>> conditionally evaluated be exported. |
10 |
> Well what are you planning to use it for? Are you really suggesting |
11 |
> that people are going to implement EAPI-aware, compliant dependency |
12 |
> parsers that can't figure out conditionals? |
13 |
|
14 |
No, but the resolution of the conditionals may change over time and it |
15 |
would be nice to have the information as it was at the time of the |
16 |
build. However, this point is minor. I'm certain something can be |
17 |
worked out among the PMS people as to what is best here. After all, the |
18 |
request did come from the portage camp. |
19 |
|
20 |
> |
21 |
>> 1) This cannot be utterly arbitrary because there are utilities and |
22 |
>> portions of portages code which does make use of precisely this |
23 |
>> information. |
24 |
> What Portage does internally is up to Portage. What we don't want is to |
25 |
> encourage external utilities that are utterly inflexible and that make |
26 |
> strange assumptions. |
27 |
|
28 |
Neither do we want to hamper what developers might want to do. The |
29 |
authors of sys-apps/elfix, app-portage/gentoolkit, |
30 |
app-portage/portage-utils, app-portage/eix are not "utterly inflexible" |
31 |
utilities makeing "strange assumptions". They are useful utilities as |
32 |
anyone following this thread would agree. Their assumption would go |
33 |
from being non-standard to standard with the acceptance of this GLEP. |
34 |
They would then operate with both portage and paludis. |
35 |
|
36 |
> |
37 |
>> 2) With the exception of some embedded systems where everything is |
38 |
>> statically linked, all modern systems have dynamic linking. And all |
39 |
>> dynamic linking has information in its objects which associates the |
40 |
>> executables with the library they link against. This is the |
41 |
>> essential information to be stored. |
42 |
> Which isn't what you're asking for... You're asking for it in a |
43 |
> particular format. |
44 |
|
45 |
I will incorporate better language which goes to the heart of what's |
46 |
needed and makes the ELF quantities an example rather than the demanded |
47 |
format. In other words, I will remove the ELF bias. Since dynamic |
48 |
linking information is generated at build time, is expensive to |
49 |
regenerate and is useful to other utilities, it falls under the scope of |
50 |
the GLEP. Of course we wish to extend this to any executable format. |
51 |
We focus on ELF because of its familiarity, but not at the exclusion of |
52 |
others. |
53 |
|
54 |
> |
55 |
>> 6) Without a standard here, we have utilites which make use of this |
56 |
>> cached information in the tree which only work with portage but not |
57 |
>> paludis. This problem can be solved by removing those utilities, |
58 |
>> which is undesireable, by standardizing what needs to be exported |
59 |
>> from the PM, or by living with the status quo which is having useful |
60 |
>> packages in the tree which don't work with paludis. |
61 |
> The solution is to replace those utilities with something that works in |
62 |
> proper generality. |
63 |
|
64 |
You can do this, but it would be terribly inefficient to regenerate |
65 |
expensive information already generated by PM. For example, `equery` |
66 |
from gentoolkit allows the user to gather all sorts of information about |
67 |
installed packages, eg. "What package does this file belongs to?" A |
68 |
very natural question. Without this information cached in portage's |
69 |
VDB, how would equery do this? It would have to rebuild package by |
70 |
package until it finds one that gives the file we're looking for?! This |
71 |
is absurd. Rather gentoolkit opens up /var/db/pkg and read the |
72 |
information out of there. |
73 |
|
74 |
For gentoolkit to work "in proper generality" we would need PM's to |
75 |
export this information by some common API, so there is a generality. |
76 |
That's what GLEP 64 is about. You point argues in favor of the GLEP. |
77 |
|
78 |
|
79 |
> |
80 |
>>> You've also not discussed how this interacts with Portage's |
81 |
>>> package.provided misfeature. |
82 |
>>> |
83 |
>>> Finally, you don't have any way of using this information, since you |
84 |
>>> don't have a way of knowing what packages are installed. |
85 |
>> I don't understand your reasoning behind these points, can you please |
86 |
>> explain. |
87 |
> Well you can't ask for information about packages unless you know |
88 |
> what's installed, and you haven't asked for a general API for that. |
89 |
|
90 |
Ah, okay. That should be added explicitly since its only implied right |
91 |
now. Thanks. |
92 |
|
93 |
> |
94 |
> And when you do ask, is a package that's "provided" installed, and if |
95 |
> so, what's its metadata? |
96 |
> |
97 |
|
98 |
When the package is installed, that data should have been cached. |
99 |
|
100 |
-- |
101 |
Anthony G. Basile, Ph.D. |
102 |
Gentoo Linux Developer [Hardened] |
103 |
E-Mail : blueness@g.o |
104 |
GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA |
105 |
GnuPG ID : F52D4BBA |