Planning for R-repo...

All the specs are on github and
still a number of them needs to be finish actually (quite a number of
empty %file section as the build didn't finish).

On the script repo I have the script to find the packages that needs
update.
I normally also have the script to rebuild the update.

What's lacking will be
- time
- feedback that it works (or not)
- cronjob on the scripts (at least part of them) :)

I've got some strong motivation to help nudge this process towards 
automation.  I think the lack of a good R repo for redhat-like distros 
is a horrid lack.  I do enough work to maintain our little corner of 
packages, if I can do a bit more and help make One Repo to Rule them 
all, that'd be great.

I think it's worthwhile to chew on the structural obstacles (that *#(@ 
dependency map) because if we can get beyond that, we can be more 
automatic.  The long term time savings would be huge.

But I really want to proceed in a way that is aligned with where you're 
driving, Pierre-Yves:  the work I did in ca. 2009 was clearly not 
aligned with where you're going, and I don't want to lose more such 
effort.   So I want to start from scratch, to figure out where you want 
to go.

----

I see several structural issues:   Dependency loops,  and unstated or 
incorrectly (inconsistently?) stated system dependencies.

The Debian R repo maintenance folks keep a list of metadata they need to 
resolve issues in the builds.   We might do something similar:  A 
human-decided list of facts like

'Package GDD has a system dependency of "libgd" '

and

'It's safe to cut the dependency link that says RColorBrewer depends on 
ggplot2'

could eventually converge on a state where we could Just Automatically 
Do It.


We might also simplify our building graph if we think about a build 
session in two phases:  One for 'what are the deps we need to build this 
package?', and a separate phase for 'what are the deps we need to 
_check_ this package?'

This would require we have a distinction, between a package we've built, 
and a package we've "blessed", if I may use the term.


Am I making sense?



- Allen S. Rout