1 |
On Tue, 01 Apr 2008 16:11:10 +0200 |
2 |
René 'Necoro' Neumann <lists@××××××.eu> wrote: |
3 |
> >> Ok. Perhaps we can postpone this until it gets real. (And then |
4 |
> >> perhaps use scpvr's ;) ... like: cpan:bla-foo/SomePerlPkg-0.13) |
5 |
> > |
6 |
> > Paludis does it already. |
7 |
> |
8 |
> So we can set it as the package format? (Though needing further |
9 |
> definitions.) |
10 |
|
11 |
Mm? With Paludis you get things like CRAN as 'just another repository'. |
12 |
|
13 |
> > How does Paludis know which configuration set it should be using to |
14 |
> > respond to queries? |
15 |
|
16 |
When you invoke a Paludis client you can use --environment to specify |
17 |
a configuration set. |
18 |
|
19 |
> Ok - so we need sessions ... |
20 |
> |
21 |
> I see two possibilites to implement it: |
22 |
|
23 |
The third is to have different DBus services per configuration. |
24 |
|
25 |
> That's true. But I want it for three reasons: |
26 |
> - - no security issues |
27 |
> - - safe way is more important than nice way: In case the information |
28 |
> catapult provided (e.g. dep tree) is not correct (for whatever |
29 |
> reason), I don't want it to crash the users system. Thus, it is |
30 |
> better to let the package manager to have the final say. - This |
31 |
> reason gets obsolete if the providers are maintained by the package |
32 |
> manager teams themselves, but this is not the case atm. |
33 |
> - - at least in portage I can't see a way to say "hey - portage: |
34 |
> install the following packages please", as the logic behind this is |
35 |
> done in emerge itself. |
36 |
> |
37 |
> Is there any other reason to vote against this besides "isn't the |
38 |
> nice way"? |
39 |
|
40 |
Yeah. You can't use it to write a decent client. More on that below. |
41 |
|
42 |
> > Doesn't make much difference either way... Why is the revision the |
43 |
> > only version part you treat specially? |
44 |
> |
45 |
> We could also return "" instead "-r0" if no revision is given. Does |
46 |
> not make a difference. |
47 |
|
48 |
Why split revision at all? |
49 |
|
50 |
> Now I see, why you want the user to know of the EAPI... Do you think |
51 |
> it would be enough to allow to query the EAPI value of a package? Then |
52 |
> (taking this example) the client can decide whether to ask for |
53 |
> "DEPEND" or "DEPENDENCIES" depending on the EAPI. |
54 |
> If for some reason, he asks for "DEPEND" and the package uses EAPI2 an |
55 |
> EAPIError or something similar is being thrown. |
56 |
|
57 |
The issue with doing things that way is that every single client has to |
58 |
be updated for every new EAPI. |
59 |
|
60 |
It's probably useful to look at how Paludis and Portage handle EAPIs. |
61 |
Portage basically just has some hardcoded if-else logic ("if the EAPI |
62 |
is 1 then ...") in relevant areas (and doesn't generally enforce EAPI |
63 |
things). This has the advantage that it's quick to code if you have a |
64 |
small number of relatively similar EAPIs. It has the disadvantage that |
65 |
when we introduce a new EAPI someone has to go through and check all |
66 |
those code paths, and add a bunch more. It doesn't scale well to large |
67 |
changes. |
68 |
|
69 |
Paludis does things differently. EAPI-dependent code never directly |
70 |
queries EAPI. Instead, it queries a central class for capabilities |
71 |
(things like "does this EAPI support slot deps?" or "does this EAPI |
72 |
use an ECONF_SOURCE-aware src_compile?"). And rather than hardcoding |
73 |
configuration keys ("get me the DEPEND string" and so on), we have an |
74 |
abstracted high-level interface ("get me the key that holds |
75 |
dependencies that have been parsed into an abstract higher level |
76 |
format") that's sufficiently powerful to deal with all EAPIs, along with |
77 |
non-ebuild packages. This means that clients written using the Paludis |
78 |
EAPI (and, indeed, the core Paludis library) have absolutely no mention |
79 |
or awareness of EAPI anywhere, and yet always behave correctly for all |
80 |
EAPIs. |
81 |
|
82 |
Forcing every client to be EAPI aware and updated for every new EAPI is |
83 |
majorly sucky. On the other hand, the Paludis approach quite possibly |
84 |
only works because we have strong static checking and rich classes... |
85 |
|
86 |
> > The package manager handles || on a case by case basis. Anything |
87 |
> > containing || cannot be flattened to a simple list. |
88 |
> |
89 |
> When installing the the package the package manager is taking one of |
90 |
> the choices of "||", based on certain information. A similar approach |
91 |
> should be used here too. |
92 |
|
93 |
That certain information is the key issue. That certain information, in |
94 |
the dependency resolution case, is a rather complex context that can |
95 |
include things like speculative branch taking on earlier || cases, |
96 |
speculative unmasking and knowledge of packages that aren't installed |
97 |
yet but that will be by the time the ID providing the || is reached for |
98 |
install. |
99 |
|
100 |
For example... The Paludis handling code for || ( ) deps when resolving |
101 |
a normal dependency goes very roughly like this: |
102 |
|
103 |
- Is the || ( ) block empty after removing use? blocks? If so, pretend |
104 |
it's empty. |
105 |
|
106 |
- Try to rewrite the || ( ) block to a single multi-operator dep spec, |
107 |
and use that instead of the || ( ) block if we can. |
108 |
|
109 |
- Are any of the || ( ) children already installed? (Note that this |
110 |
handles complex blocks and the like too...) If so, take that child. |
111 |
|
112 |
- If we have something like || ( a >=b-2 ) and b-1 is installed, take |
113 |
the b-2 branch if we can do so. |
114 |
|
115 |
- Go for the first viable option. |
116 |
|
117 |
- Fall back and go for the first option to get an exception. |
118 |
|
119 |
You can't emulate this logic by flattening. |
120 |
|
121 |
> >> Just return some kind of an URL. The end tool has to deal with it. |
122 |
> > |
123 |
> > Then the name needs changing, and it needs to be documented that the |
124 |
> > return value is entirely meaningless. |
125 |
> |
126 |
> Name change ok - perhaps s/path/url/ ? |
127 |
> |
128 |
> "entirely meaningless" - I would use "might be meaningless" instead. |
129 |
|
130 |
So what's the URL for what Paludis calls VirtualsRepository or |
131 |
InstalledVirtualsRepository? |
132 |
|
133 |
> > But they can't write to cache on disk. Remember that Portage needs |
134 |
> > you to be in the 'portage' group to do anything, and anyone in the |
135 |
> > 'portage' group can easily obtain root on the box. |
136 |
> |
137 |
> Nope - you can query even if you are not in the portage group. |
138 |
|
139 |
Really not a good idea... |
140 |
|
141 |
> Despite the current open issues (btw: I tried to collect them on a |
142 |
> wiki page: http://catapult.origo.ethz.ch/wiki/current_issues ), do |
143 |
> you think that the whole system can be brought to something useful in |
144 |
> the end? |
145 |
|
146 |
I think you have one big issue: you don't have a clear purpose for the |
147 |
API. |
148 |
|
149 |
On the one hand, you're saying that it should be a nice simple API for |
150 |
clients. |
151 |
|
152 |
On the other hand, you're saying that you want to use it for writing a |
153 |
nice fancy GUI. |
154 |
|
155 |
Of the Paludis clients we've experimented with, the one that makes by |
156 |
far the most complex use of the API is the GUI client. This isn't |
157 |
merely because we can -- the only time a GUI becomes useful is when it |
158 |
offers functionality that can't easily be provided quickly by a non-GUI |
159 |
client. A GUI should be able to do things like display a resolution of |
160 |
'update world with deps', and have little clicky things on each item |
161 |
saying things like "exclude this from the update" (greyed out if the |
162 |
item can't be excluded), "show me a tree of why this package is |
163 |
included in the list" and "select a different item from the || ( ) |
164 |
branch that pulled this dep in". You can't do this without an extremely |
165 |
rich API (and you probably can't do it without lambdas hooked into the |
166 |
resolver...). You definitely can't do this by having a crude "give me a |
167 |
command I can exec()" way of installing things. |
168 |
|
169 |
-- |
170 |
Ciaran McCreesh |