On Sat, 2012-05-12 at 13:45 +0100, José Matos wrote:
On 2012-02-29 21:21, Pierre-Yves Chibon wrote:
> On Wed, 2012-02-29 at 19:21 +0000, José Matos wrote:
>> After almost two months going on what is the outcome of this project?
> Well the structure is there and a number of rpms available.
> I have started on the update mechanism but I have only got around the
> first round.
> The spec are on github and I have no problem giving the rights to commit
> if people are interested (<hint>, <hint> ;-)).
After June 11th sure, until there I have 18h of classes per week for
undergrads, master and phd students and with a seven months old lovely
daughter there is not much of free time, oh and surely the scouts
My last surge for build R packages for Fedora is due to the academic work.
I have several students doing their master thesis using stochastic
differential equations in several domains and for that I suggested them
to use R packages since R is a language they learn in the course.
One of the packages that is appropriate is the Sim.DiffProc package. For
that package the chain dependency is relatively simple.
So if you do not mind I have several questions regarding this issue.
1) Why is r-repo.org
not available for Fedora? Lack of time is a fair
Time is definitively part of the answer the other part being the
challenge of rebuilding the repo once in a while when necessary.
2) I noticed that you have R-xlsxjars packaged in r-repo, from a
glance it looks like it just packages a set of jar files. I am clueless
when it comes to java but are not those some kind of binary files that
could be replaced using dependencies for system libraries? I am aware
that jars can have different purposes but I am asking anyway.
R can be coupled with java as it can be with C/C++/fortran &so on, I
*assume* that this is what was done in this package (again, *assumed*).
If it is not the case, then for sure it should not be this way and it
should rely on system libraries.
R-repo is/was aiming at automatically generated RPM which mean that a
number of them are not 100% valid. At least it gives us a basis for
I have to say that from my side time is truly limiting and the situation
won't change (it will even get worse) with the fact that I am starting
the last year of my PhD but at least this time everything is publicly
available on github if there are people interested in the
maintenance/development of the project.
>> Back in September I wanted to package some R libraries and
>> some time to get all the packages due to the build requirement of each
>> package, I had to unravel the dependencies while deciding what was
>> necessary to bootstrap the process, and not even speaking about
>> circular references. Clearly a fun project... :-)
> <irony>hm R ? circular dependencies? I think I've heard about that once
> or twice </irony>
Do you have any idea of how R install.packages deals with these cases?
To be honest, I do not know, but I am not sure install.packages runs the
tests and thus it likely doesn't run into the circular dependency
problem which are most of the time of the type: A requires B which
suggests A (or similar).
While searching for further information I noticed that the
effort on the debian side is cran2deb
and the active repository is available at http://debian-r.debian.net/
From the available discussion and from my previous work I know that
there are several issues to be tracked. One of them is the package
license and the other are the external (system libraries) dependencies.
Is this information stored in any central place (database)?
There are no form of license check done atm in R-repo and it doesn't
rely on a central database.
The dependency tree is built by parsing the PACKAGES files from the
The R-repo-utility  contains the script doing the work (building the
tree, building the RPMs, checking for updates and so on).
Let me know if I can be of any help.