GDAL 1.7.3 / Java software and repos (was Re: [El] imageio-ext)

[Ralph Apel]

JPP6-devel is a sort of "testing" repo. Many of those packages have been
(or will be) later moved to "-free". 
But I have pushed several geoscience packages or requirements of
geoscience packages to JPP6-devel and JPP6-free as well. IMHO these
should be maintained outside of JPP, just as we should not fork general
purpose java stuff from JPP.

On Thu, 2010-11-25 at 09:36 +0100, Mathieu Baudier wrote:
> Hi Ralph,
> 
> > Here I'm submitting
> 
> thanks a lot for this effort!
> 
> Now, I would like to take a step back in order to better understand
> all that was produced and see how and where we can integrate this.
> 
> 1. GDAL 1.7.3
> It is not clear to me which spec file / SRPM would build against EL 5 / EPEL 5.
> Can you please point us to it?
> 
> We need a GDAL package that does not require to update the base OS.
> Is it ok?
> Do we now need additional repos (JPP?) for GDAL?
> 
> > - the mock config I used (/etc/mock/elgis-5-jpp-testing-i386.cfg)
> 
> 2. I had a quick look at your mock config file and I have a few questions:
> 
> - why is there JPP 5 and JPP 6?
> - does including JPP (esp. the -devel) mean that we upgrade part of the base OS?
> - what is your "custom" repo? was it only for your intermediary builds?
> 
> > - the spec I used
> 
> I would suggest the follwoing approach:
> - let's first have a proper GDAL 1.7.3 package (maybe we will have to
> split it, in order to keep a "core" with limited dependencies)
> - then let's discuss how we can manage the additional JPP repos.
> - then start integrating the complex JNI dependencies (imageio, JAI, ...)
> 
> An approach could be to create yet another repo (elgis-jpp?), but this
> would add complexity.
> So maybe we should put all that in elgis-plus were we have maximal flexibility.
> 
> If the JPP used does not upgrade base (see my questions above) then we
> can discuss adding it has a required repo, in addition to EPEL. But
> this may also make a first configuration more complex for a new user,
> who would not necessarily be interested in Java software.
> 
> We could also rebuild and host all the required packages, but this
> look like a huge piece of work, and doesn't feel right.
> 
> There is also the question of whether EPEL 5 would be interested in
> taking all this over (EPEL 6 is in good hands with all the work that
> Viji is currently putting into it, so there is no need for ELGIS to
> focus on EL 6 from a packaging point of view).
> My current understanding/feeling is that EPEL 5 would rather stay
> "stable", and that the ELGIS repos are the place where we can play
> around in order to support the latest GIS software on the EL 5
> platform. But as already discussed, all possibilities are open.
> 
> Looking forward to comments/ideas...
> 
> Cheers,
> 
> Mathieu