[R-sig-Fedora] Planning for R-repo...

[Pierre-Yves Chibon]

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 *#(@ 
> 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 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.

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)

So hopefully we would face the dependency issues only in stage 1 and 3
(and eventually 4). So if package X requires something outside R
repository, you will detect it at stage 3 and fix it once and for all.

I might have an idealistic vision of the reality here, so I went for a
simple scheme.

I hope that by using git/github we can gather a group of interested
people who can just submit merge request to fix the spec files.
From there build and pushing the updates should not be too hard for me
(at first but in a longer time, I hope, for us).

How does this sound for you?

Basically, I think what you were saying makes sense and is the most
sensible approach. First get auto-generated spec files, then review them
by hand to fix build problems.
For the dependencies, the two steps approach you were referring to is
probably the best approach. First build with the minimum dependencies
then rebuild as the other have become available. Now that we have the
first round in place and available we can start working on the second
run.

Do I make sense? Is this sensible?

Regards,
Pierre