| 1 |
Alright, so I experimented a bit with G-CPAN and read some of its |
| 2 |
code, and it kind of works as I expected. I also spoke with some |
| 3 |
paludis devs (including the chief), and they told me that basically a |
| 4 |
lot of CRAN packages are illegal in some of way. It's usually the |
| 5 |
version that's got a wrong format, but the metadata files are slightly |
| 6 |
incorrect in general. If I would get this to work, we will need to |
| 7 |
file loads of bugs upstream to improve their repo quality. Having |
| 8 |
spoken with some guys in #R, this seems to be no problem, the CRAN |
| 9 |
maintainers would love QA improvements. |
| 10 |
|
| 11 |
I also looked into cran2deb, and it's basically not unlike G-CPAN, |
| 12 |
except that it directly builds and then generates a .deb file. The |
| 13 |
magic happens in /R/build.R, all the way at the bottom. |
| 14 |
|
| 15 |
Another thing. Bioconductor, another source of R packages, uses |
| 16 |
exactly the same format as CRAN, so if I can get CRAN packages to |
| 17 |
build, Bioconductor packages will install just as smoothly. |
| 18 |
|
| 19 |
I guess this sums up my findings, and I don't think I'm really missing |
| 20 |
any critical information. I would like to hear any further ideas, and |
| 21 |
would appreciate a mentor, but I guess mentors are usually assigned |
| 22 |
after the application period, so perhaps I should start writing an |
| 23 |
application. |
| 24 |
|
| 25 |
Thanks, |
| 26 |
tulcod. |
| 27 |
|
| 28 |
PS: an overview of the quality of packages in CRAN can be found at this link: |
| 29 |
http://cran.r-project.org/web/checks/check_summary.html |
| 30 |
|
| 31 |
2010/3/19 Sébastien Fabbro <bicatali@g.o>: |
| 32 |
> On Friday 19 March, Auke Booij wrote: |
| 33 |
> |
| 34 |
>> Please forgive me for my lack of knowledge about package managers, but |
| 35 |
>> what systems are in place to generate ebuilds on the fly? And is there |
| 36 |
>> any compatibility between the different package managers in that |
| 37 |
>> sense? Would it be possible to make an overlay build a repository of R |
| 38 |
>> packages on the fly? If ebuilds are generated on the fly, how will we |
| 39 |
>> deal with nontrivial ebuilds? |
| 40 |
>> |
| 41 |
>> As always, there are a number of advantages to make the package |
| 42 |
>> manager do the hard work. I guess some more benefits would, among |
| 43 |
>> many, be: emerge world updates R packages too (ie. centralized |
| 44 |
>> updating), packages in portage can pull in R packages without user |
| 45 |
>> interference, and users can relatively easily install R packages with |
| 46 |
>> patches. |
| 47 |
> |
| 48 |
> Experiment with g-cpan and g-ctan in the portage tree to have an idea |
| 49 |
> of what is done. Indeed working directly with the package manager is |
| 50 |
> more appealing for many reasons: dependencies, QA, convenience, ...For |
| 51 |
> differences between package managers, see with the different parties |
| 52 |
> involved. To my knowledge only paludis had some CRAN integration at |
| 53 |
> some point. Also Debian has a cran2deb utility which is probably |
| 54 |
> worth looking into, they actually had a GSoC 2008 project about it. |
| 55 |
> |
| 56 |
> Sebastien |
| 57 |
> |
| 58 |
> |
Archives