1 |
Last week I promised: |
2 |
"Soon to come is proper parsing of the License field, proper |
3 |
translation of dependencies (the current code assumes a dependency on |
4 |
foo means a dependency on dev-R/foo) and installing /usr/share/doc |
5 |
files correctly." |
6 |
|
7 |
Well, I have very good news. The License field gets parsed almost |
8 |
properly, documentation files get installed almost correctly, and |
9 |
dependencies are almost translated properly. |
10 |
|
11 |
No, it's not perfect yet. If the license is really a reference to a |
12 |
LICENSE file (instead of just the name of the license), it does not |
13 |
get installed, nor displayed correctly. If the documentation isn't |
14 |
just HTML documentation, it doesn't get installed. If a dependency is |
15 |
really already part of the default R install, it's not discarded and |
16 |
the package will depend on a nonexistent package, and this is |
17 |
something I'd like to hear your thoughts on (see below). |
18 |
|
19 |
Unfortunately, g-common isn't really getting anywhere yet. I hope some |
20 |
more emailing will get us started, but else I'll be developing my own |
21 |
system. If I will, then a big advantage would be that I can simply |
22 |
implement it the way I'd like to, instead of having to convince the |
23 |
other two GSoC devs first ;-) |
24 |
|
25 |
Alright, discarding dependencies. Some (a lot of) CRAN-style packages |
26 |
depend on libraries which already get installed as part of the R |
27 |
program. These dependencies should, for our purposes anyway, simply be |
28 |
discarded, but to do this I do need to know what libraries are part of |
29 |
the default R install, which means listing R's files, and I'd like you |
30 |
guys to tell me how to do this. As far as I can see, the following are |
31 |
the options and I'd like to hear which you would prefer: |
32 |
-use "qlist" or "equery files" |
33 |
-read it from the vdb |
34 |
-hardcode the list of builtin R libraries |
35 |
-read it from the filesystem directly (note: this would mean that some |
36 |
correct dependencies are discarded as well, but it is a very |
37 |
lightweight and independent solution) |
38 |
Pros, cons? Opinions wanted! |
39 |
|
40 |
Up for next week is, first of all, finishing the dependency stuff, and |
41 |
if I'm lucky some initial development on g-common. The week after that |
42 |
I will still be working on g-common, and perhaps do some initial |
43 |
QA. |