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

[Ralph Apel]

Sun-Java is not an issue with gdal nor with imageio-ext as such.
It is an issue with jai-core.

I have put these packages into the "custom" local repo with the purpose
of building jai-core:

$ ls -1 /home/rapel/mirror/elgis/custom/
java-1.6.0-sun-1.6.0.20-1jpp.i586.rpm
java-1.6.0-sun-alsa-1.6.0.20-1jpp.i586.rpm
java-1.6.0-sun-demo-1.6.0.20-1jpp.i586.rpm
java-1.6.0-sun-devel-1.6.0.20-1jpp.i586.rpm
java-1.6.0-sun-fonts-1.6.0.20-1jpp.i586.rpm
java-1.6.0-sun-jdbc-1.6.0.20-1jpp.i586.rpm
java-1.6.0-sun-plugin-1.6.0.20-1jpp.i586.rpm
java-1.6.0-sun-src-1.6.0.20-1jpp.i586.rpm
repodata

Then, for the build of imageio-ext, the "newbuilds" local repo was
completed like

$ ls -1 /home/rapel/mirror/elgis/newbuilds/
gdal-1.7.3-1.el5.elgis.i386.rpm
gdal-1.7.3-1.el5.elgis.src.rpm
gdal-debuginfo-1.7.3-1.el5.elgis.i386.rpm
gdal-devel-1.7.3-1.el5.elgis.i386.rpm
gdal-java-1.7.3-1.el5.elgis.i386.rpm
gdal-perl-1.7.3-1.el5.elgis.i386.rpm
gdal-python-1.7.3-1.el5.elgis.i386.rpm
gdal-ruby-1.7.3-1.el5.elgis.i386.rpm
gdal-static-1.7.3-1.el5.elgis.i386.rpm
jai-core-1.1.3-2.el5.elgis.i386.rpm
jai-core-1.1.3-2.el5.elgis.src.rpm
jai-core-debuginfo-1.1.3-2.el5.elgis.i386.rpm
jai-core-javadoc-1.1.3-2.el5.elgis.i386.rpm
repodata


On Thu, 2010-11-25 at 15:21 +0530, Viji V Nair wrote:
> Hi
> 
> On Thu, Nov 25, 2010 at 2:06 PM, Mathieu Baudier <mbaudier at argeo.org> 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?
> 
> Yes, in my opinion also, it should not. It will break unexpected stuffs...
> 
> > Do we now need additional repos (JPP?) for GDAL?
> 
> As we discussed earlier, there are two issues, actually three.
> 
> 1. The native *jni.so which we have included in the gdal-jni package
> 2. The patched ones for imageio (we cannot have both the normal and
> patched version installed on the same machine)
> 3. 1 and 2 with Sun/Oracle JDK
> 
> So, the gdal-java package will have two versions, I would suggest we
> will use Sun Java and patch the same for imageio and keep it in a
> separate repo, elgis-plus
> 
> >
> >> - 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)
> 
> We need to split gdal-java only
> 
> > - 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.
> 
> This will be more complex..
> 
> We will try on:
> 
> EL/ELGIS 5 : Keep as its is, more stable
> ELGIS PLUS : We can play around
> 
> EPEL6 : Upcoming stable branch
> ELGIS6 : Very limited things those have absolutely no hope in EPEL6
> 
> > 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.
> 
> Not a good idea at this moment, need to focus on EPEL 6
> 
> >
> > 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
> > _______________________________________________
> > el mailing list
> > el at lists.osgeo.org
> > http://lists.osgeo.org/mailman/listinfo/el
> >
> 
> Thanks
> Viji