Gentoo Archives: gentoo-soc

From: Auke Booij <auke@××××××.com>
To: gentoo-soc@l.g.o
Subject: [gentoo-soc] G-CRAN weekly report #1
Date: Mon, 31 May 2010 19:59:26
Message-Id: AANLkTilD7zq9AQm0CmD87dSkc8uKfAO0dK2wfUQQh6hx@mail.gmail.com
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.