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

[Ralph Apel]

No additional repos needed for gdal.

JPP6 is incomplete, not released yet. Some artifacts must still be
pulled from JPP5. Porting such packages to JPP6 is not difficult - just
a matter of being industrious :-)

In the case of the imageio-ext build, i.e.:

maven-shared-archiver.noarch 0:2.3-0.p8.5.jpp5
velocity14.noarch 0:1.4-8.jpp5
asm.noarch 0:1.5.3-7.jpp5
backport-util-concurrent.noarch 0:3.1-3.jpp5
checkstyle4.noarch 0:4.4-4.jpp5
commons-build-plugin.noarch 0:1.1-1.jpp5
ecj.noarch 1:3.3.1.1-3.jpp5
ganymed-ssh2.noarch 0:210-5.jpp5
gnu-regexp.noarch 0:1.1.4-13.jpp5
jetty6.noarch 0:6.1.14-1.jpp5
jetty6-core.noarch 0:6.1.14-1.jpp5
jetty6-servlet-2.5-api.noarch 0:6.1.14-1.jpp5
jline.noarch 0:0.9.94-1.jpp5
jmock.noarch 0:1.2.0-2.jpp5
junit4.noarch 0:4.5-4.jpp5
junit44.noarch 0:4.4-1.jpp5
jzlib.noarch 0:1.0.7-4.jpp5
kxml2.noarch 0:2.2.2-3.jpp5
maven-jxr.noarch 0:2.1-2jpp
maven-release.noarch 0:4-2jpp
maven-shared.noarch 0:8-0.p8.5.jpp5
maven-shared-common-artifact-filters.noarch 0:1.0-0.p8.5.jpp5
maven-shared-dependency-tree.noarch 0:1.1-0.p8.5.jpp5
maven-shared-file-management.noarch 0:1.2-0.p8.5.jpp5
maven-shared-invoker.noarch 0:2.0.7-0.p8.5.jpp5
maven-shared-io.noarch 0:1.1-0.p8.5.jpp5
maven-shared-jar.noarch 0:1.1-0.p8.5.jpp5
maven-shared-monitor.noarch 0:1.0-0.p8.5.jpp5
maven-shared-osgi.noarch 0:0.2.0-0.p8.5.jpp5
maven-shared-plugin-testing-harness.noarch 0:1.2-0.p8.5.jpp5
maven-shared-plugin-testing-tools.noarch 0:1.0-0.p8.5.jpp5
maven-shared-reporting-impl.noarch 0:2.1-0.p8.5.jpp5
maven-shared-repository-builder.noarch 0:1.0-0.p8.5.jpp5
maven-shared-test-tools.noarch 0:1.0-0.p8.5.jpp5
plexus-ant-factory.noarch 0:1.0-0.a1.4.jpp5
plexus-archiver.noarch 0:1.0-0.2.a7.5.jpp6
plexus-bsh-factory.noarch 0:1.0-0.a7s.4.jpp5
plexus-compiler.noarch 0:1.5.3-3.jpp5
plexus-i18n.noarch 0:1.0-0.b6.5.jpp5
plexus-interactivity.noarch 0:1.0-0.a5.6.jpp5
plexus-utils.noarch 0:1.4.8-2.jpp5
pmd.noarch 0:4.2.5-1.jpp5
rat-lib.noarch 0:0.5.1-1.jpp5
saxon.noarch 0:6.5.5-1.jpp5
saxpath.noarch 0:1.0-3.jpp5
xmlrpc2.noarch 0:2.0.1-5.jpp5


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