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

Viji V Nair viji at fedoraproject.org
Thu Nov 25 04:51:00 EST 2010


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


More information about the el mailing list