1 |
My development started by examining the R package format, which |
2 |
honestly is pretty straightforward. A lot of data can be retrieved |
3 |
from a repository file called PACKAGES, and each package has its own |
4 |
metadata files. I've read the paludis source code, and the C++ part |
5 |
simply makes sense, but the true piece of gold is a file called |
6 |
cran.bash, which will be a huge source of inspiration for the code |
7 |
which will actually build and install CRAN/Bioconductor packages. |
8 |
|
9 |
More importantly than all the above, I've found a few like-minded |
10 |
(well, at least they're like-minded now) fellow Gentoo SOC students |
11 |
(wiktor_b and iElectric) with whom I'll be creating a generic solution |
12 |
for non-ebuild repositories. There's a fourth student doing a similar |
13 |
project for Octave/Matlab packages (rafaelmartins), but he's already |
14 |
started and would rather stick to his own schedule and will not be |
15 |
cooperating with us, apart from an incidental sharing of thoughts. |
16 |
|
17 |
While it's not entirely clear how package managers should support our |
18 |
new system eventually, any package manager that doesn't support it is |
19 |
given an ebuild which "forwards" actions to the right package format |
20 |
"driver". This forwarding is regulated by the main system, called |
21 |
g-common, and individual drivers can specify how to build packages |
22 |
correctly. We've documented our approach in a wiki and the design we |
23 |
eventually settled for is called "interface 1" (a previous design |
24 |
called "interface 0" was quickly blown to smithereens by yours truly). |
25 |
|
26 |
We've more or less agreed on an approach for this system and for now |
27 |
we'll go on by individually writing the drivers, still meeting weekly |
28 |
but only continuing development on g-common in about 3 weeks. |