Welcome to R-Forge Site Admin project!

This project contains the R-Forge site itself. Bugs, feature requests regarding R-Forge can be send with the implemented tracker.

R-Forge Build Check Schedule

Rebuild R: 19:00 CET.

Exportation of R package sources (this also includes an update of the R Packages tab): 20:30 CET.

Sync unpacked package sources to build machine: 21:45 CET.

Building of R source packages (.tar.gz): 22:30 CET.

Sync package sources (.tar.gz) to R-Forge: 23:30 CET.

Sync package sources (.tar.gz) to build machines: 23:45 CET.

Building of Windows binary packages: 0:00 (patched), 12:30 (devel) CET.

Building of Mac OS X (universal) binary packages: 0:00 (patched) CET.

Sync package binaries (.zip, .tgz) and build logs to R-Forge: 2:30 CET.

Sync package sources to check machines (.tar.gz): 1:30 CET.

Check packages (Linux): 2:00 (devel), 10:00 (patched) CET.

Check packages (Windows): 2:00 (devel), 10:00 (patched) CET.

Check packages (Mac): 2:00 (patched) CET.

Sync check results to R-Forge: 11:00, 19:00 CET.

Build/check cycle completed.

Resolving Package Dependencies

Suppose for example that R-Forge may also host development releases of packages already available from CRAN (or other repositories) possibly with a higher version number. Let d_CRAN(P) and d_R-Forge(P) be the dependencies of a package P hosted on CRAN and R-Forge, respectively. How does R-Forge consider these dependencies? Our current solution is to calculate the dependency structure in the following way: First all d_CRAN(P) and then d_R-Forge(P) \ d_CRAN(P) are installed. This allows that all d(P) are available but forces the system to use d_CRAN(P) with higher priority. This decision reflects the fact that CRAN packages are known to be stable and work. However, in certain circumstances developers may want the system to use (some of) d_R-Forge(P) instead. This feature is not implemented yet.

For general information about this project please visit the project summary page.