This list is for people using the Fedora RPMs of R and its packages. The main purpose of the list is to allow rapid testing of updated RPMs using Fedora's peer review system. ()

headers Allen S. Rout | 13 Mar 2012 22:04

On a totally different topic (or maybe not so different)...

I noticed that r-repo.org's first release is also its last release. 
What's blocking you?  Can I help?

- Allen S. Rout

On Tue, 2012-03-13 at 17:04 -0400, Allen S. Rout wrote:
> 
> On a totally different topic (or maybe not so different)...
> 
> I noticed that r-repo.org's first release is also its last release. 
> What's blocking you?  Can I help?

Nothing is really blocking but time. 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) :)

Pierre

On 03/13/2012 05:12 PM, Pierre-Yves Chibon wrote:
> 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 *#( <at>  
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.

On Wed, 2012-03-14 at 10:38 -0400, Allen S. Rout wrote:
> On 03/13/2012 05:12 PM, Pierre-Yves Chibon wrote:
> > 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 *#( <at>  
> 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.

On 03/19/2012 05:12 AM, Pierre-Yves Chibon wrote:

> I think the idea of R-repo is more in line with what you have in
> mind.  R2spec is a tool to generate spec file and make them as
> compliant as possible with Fedora packaging guidelines. I think it
> should remain this way.  R-repo aims at generating and providing RPM
> in an automatic way. This has pros and cons but it will be up to the
> user/sysadmin to weight them and decide to use R-repo or not.

I agree.  The critical piece I'd pick out of this is: We would like
the R-repo to be close to Fedora's guidelines, but we don't
necessarily expect to get it all the way there.

> My vision of R-repo is:
> - Generate a first layer of spec files automatically (done)
> - Build them (done)
> - Fix the one that do not build (so by hand) (started, still far from
> done)
> - Perform the updates as they are needed (I have one script but we would
> need to finish step 3 first)

Do you mean that R-repo is a published tree of specfiles?  I was
envisioning that R-repo would be a live repository of RPMs, which we
would (Hopefully, eventually) maintain not too far behind the state of
CRAN.

Then, in parallel to it, R2spec / R2rpm would be the toolset that
we're using to maintain and automate that build process.

R-repo.org ?

Re: R-repo.org ?

Planning for R-repo...

Re: Planning for R-repo...

Re: Planning for R-repo...