1 |
On Sun, 30 Mar 2008 19:30:24 +0200 |
2 |
René 'Necoro' Neumann <lists@××××××.eu> wrote: |
3 |
> Ciaran McCreesh schrieb: |
4 |
> > * use of cpv throughout. cpv isn't enough to uniquely identify an |
5 |
> > ID, especially if there're overlays. cpvr is closer, but still |
6 |
> > doesn't work if you need to deal with virtuals directly (rather |
7 |
> > than the thing provided by the virtual) |
8 |
> |
9 |
> CPVR sounds reasonable ... and what about using virtual/* for |
10 |
> virtuals? Btw: There was the idea of providing a "get_virtuals" |
11 |
> function.... |
12 |
|
13 |
The issue with virtuals is that all the package managers do them a bit |
14 |
differently. For Paludis, if you have two different providers of the |
15 |
same virtual installed with the same version and slot, you'll get two |
16 |
IDs that have the same cpvr and that are only distinguished by the |
17 |
package for which they are a virtual. This isn't an issue for us since |
18 |
we use a different PackageID instance for each, but if instead you're |
19 |
using a string to identify things (eww) you're in trouble. |
20 |
|
21 |
> > * use of regexes throughout. Every language defines its own, |
22 |
> > different regex dialect. There's no portability between languages. |
23 |
> |
24 |
> True - I thought of using some kind of globbing - thus only allowing |
25 |
> "*" and "?" (and perhaps "^" and "$") |
26 |
|
27 |
Why support it at all? That's not something that should be in at the |
28 |
package manager level. |
29 |
|
30 |
> > * No mention of EAPI anywhere. |
31 |
> |
32 |
> Why would this be needed? This is only true if "catapult API" == |
33 |
> "EAPI". |
34 |
|
35 |
Well no. When doing pretty much anything with IDs, you have to be aware |
36 |
of the EAPI. Client programs mustn't attempt to do anything with IDs |
37 |
whose EAPI they don't recognise. |
38 |
|
39 |
> > * Generally lots of hard-coded ebuildy things that don't map well |
40 |
> > onto future EAPIs or handling of non-ebuilds (e.g. native CRAN |
41 |
> > support). |
42 |
> |
43 |
> For me - gentoo package management is all about ebuilds. So I can't |
44 |
> see, what should changed there. |
45 |
|
46 |
Future-direction-wise, a lot of people are wanting to handle things |
47 |
like CPAN, CRAN, Gems etc natively in the package manager rather than |
48 |
by writing wrapper ebuilds. |
49 |
|
50 |
> > * It's tied onto a single user configuration setup, and has no sane |
51 |
> > way of handling multiple configurations or unconfigured operation. |
52 |
> |
53 |
> I don't understand this ... |
54 |
|
55 |
Paludis supports multiple configurations. You can, for example, |
56 |
have /etc/paludis, /etc/paludis-mychroot and ~/.paludis-anotherchroot, |
57 |
and Paludis can operate with all of thse. Paludis can also operate on |
58 |
systems where there's no configuration -- for example, you shouldn't |
59 |
need a full config setup just to be able to run QA checks on one |
60 |
particular repository. |
61 |
|
62 |
Portage also sort of has some of this in a very crude way, through |
63 |
PORTAGE_CONFIGROOT. |
64 |
|
65 |
> > * sets don't map on to package manager sets. |
66 |
> |
67 |
> This can easily be changed. But nevertheless, some catapult-wide sets |
68 |
> should be defined, that map onto the specific ones in the package |
69 |
> managers (e.g. catapult.SET_ALL should be replaced by the specific set |
70 |
> in the different managers) |
71 |
|
72 |
I'm not really sure that your concept of sets is right... |
73 |
|
74 |
> > - find_best. What does this do if you give it foo/bar-1 foo/baz-1? |
75 |
> Undefined atm. |
76 |
> > What's the point of having this function at all? |
77 |
> See very first remark. |
78 |
|
79 |
Sure, but you should still define your API in such a way that it's |
80 |
easily generalisable and maps well onto the underlying data. |
81 |
|
82 |
> > What if only_installed is false? Does this mean we |
83 |
> > want both not installed and installed stuff? |
84 |
> Yes. - But perhaps, instead of the "only_installed" flag used here and |
85 |
> there, a set-name should be provided. (Which then can be "installed", |
86 |
> "uninstalled" or whatever). |
87 |
|
88 |
Again, set confusion. Are you viewing set as a collection of IDs or a |
89 |
collection of specs? (It's the latter.) |
90 |
|
91 |
> > - find_packages. As find_best_match for search key. What |
92 |
> > disambiguation is performed upon the atom? What happens if you pass |
93 |
> > it something like 'git', which is ambiguous? |
94 |
> Return everything that fits. It should be on the users side to |
95 |
> translate it into something useful. |
96 |
|
97 |
That's messy. |
98 |
|
99 |
> > - get_config_path. Unportable. What if the user is using some other |
100 |
> > config format? |
101 |
> But the configs (read: package.mask, package.use etc.) have to be at a |
102 |
> specified unique location, don't they? |
103 |
|
104 |
For Paludis? No. NoConfigEnvironment, for example, uses no |
105 |
configuration directory at all. |
106 |
|
107 |
> > - get_deep_option. Deep's a mess; making package managers emulate |
108 |
> > it via a command line switch is silly. |
109 |
> If you don't have an equivalent: Return "". |
110 |
|
111 |
It shouldn't be in the API at all though. |
112 |
|
113 |
> > - get_merge_command. There's no nice way of using whatever this |
114 |
> > returns. And it's pointless -- why not just ask the package manager |
115 |
> > to do the merge? |
116 |
> Because catapult should be passive: I.E. only provide information and |
117 |
> does not do anything that could be harmful. |
118 |
|
119 |
Then it shouldn't even try to provide a way to do the merge stuff. It |
120 |
needs to either do this properly or not at all. |
121 |
|
122 |
> > - get_newuse_option. Again, unportable and messy. |
123 |
> > |
124 |
> > - get_oneshot_option. Again, unportable and messy. |
125 |
> Why unportable? - See the remarks to "--deep". |
126 |
|
127 |
Neither maps on exactly to the Paludis resolver. The Paludis resolver |
128 |
is quite a bit more flexible option-wise than what Portage offers, but |
129 |
there's no exact correspondence between options. |
130 |
|
131 |
> > - split_cpv. Why the weird revision thing? |
132 |
> What's so weired about it? |
133 |
|
134 |
Why is the revision considered special? |
135 |
|
136 |
> > - What do all of these do on unknown EAPI? |
137 |
> Again: Why does the API have to care about EAPI? - It's the providers |
138 |
> job to care about it. |
139 |
|
140 |
If you perform an API call that works on an ID with an unknown EAPI, |
141 |
what's supposed to happen? What about if you perform an API call that |
142 |
works upon an ID with an EAPI known to the package manager but not to |
143 |
the tool? |
144 |
|
145 |
(One example: what happens if we go with DEPENDENCIES for EAPI 2, and if |
146 |
you ask for DEPEND on an EAPI 2 package?) |
147 |
|
148 |
> > - compare_version. But it takes packages. What's the ordering on |
149 |
> > foo/bar-1 vs bar/baz-1? |
150 |
> Currently it would return: ("bar-1", "baz-1") as bar < baz. But this |
151 |
> can easily specified different. And a good point to think about error |
152 |
> handling again. |
153 |
|
154 |
Why the ordering on PN rather than CATEGORY/PN? |
155 |
|
156 |
> > And what's the return value? What about when || is in operation? |
157 |
> WWPMD (what would the package manager do): Simplified: Pass the |
158 |
> dep-string to the package manager and see what he does with it. The |
159 |
> result is returned. |
160 |
|
161 |
The package manager has to have special handling for || throughout. The |
162 |
behaviour of || blocks is rather tricky. |
163 |
|
164 |
> > - get_iuse_flags. What does this do for IUSE defaults? For installed |
165 |
> > packages, all flags are forced. |
166 |
> defaults are returned verbatim. I used to define "forced flags" as: |
167 |
> "The flags the user can't change." (like userland_GNU or use.mask'ed |
168 |
> flags) |
169 |
|
170 |
The user can't change any flags for installed packages. |
171 |
|
172 |
> > - get_masking_reason. Is the return value supposed to be used by |
173 |
> > anything other than a human? |
174 |
> I doubt it. |
175 |
|
176 |
Specify that. |
177 |
|
178 |
> > - get_overlay_path. What if it's in an overlay with no on-disk |
179 |
> > location? What if it's in some format the end tool doesn't |
180 |
> > recognise? |
181 |
> The end tool's problem I'd say. |
182 |
|
183 |
You're providing API calls that make this sort of thing difficult. Not |
184 |
an ideal situation... |
185 |
|
186 |
> > or when expanded keys aren't known. |
187 |
> When should that happen? |
188 |
|
189 |
Installed packages. USE_EXPAND wasn't (and still isn't by some package |
190 |
managers iirc) saved to VDB. |
191 |
|
192 |
> > What's the point in using DBus? What does it add over a simplified |
193 |
> > library with bindings? |
194 |
> |
195 |
> Library bindings have several disadvantages: |
196 |
> - - Providers have to be coded in C. |
197 |
> - - How to access portage internals from C-Code? Yes: You can |
198 |
> implement python-calls in C... but I think this is messy. |
199 |
|
200 |
You can do the translation either way. |
201 |
|
202 |
> > How does the whole privs thing work? Should anyone who can talk by |
203 |
> > DBus be allowed to perform privileged operations? Should anyone who |
204 |
> > can't perform privileged operations be allowed to do unprivileged |
205 |
> > operations? |
206 |
> I thought of having Catapult being a passive thing. So there is no way |
207 |
> of doing privileged actions. |
208 |
|
209 |
Things like querying an uncached package are privileged. |
210 |
|
211 |
> > What about persistence? What's classed as a session? Why force it |
212 |
> > down to a single session at once? |
213 |
> Easier to implement. But it isn't forced. If the provider implements |
214 |
> sessions (e.g. using the Dbus-sending-adress as a key) w/o extending |
215 |
> API, I can't see a problem. |
216 |
|
217 |
But without well-defined session management, you're stuck when it comes |
218 |
to multiple configurations and the like. |
219 |
|
220 |
-- |
221 |
Ciaran McCreesh |