[El] GDAL 1.7.3 in elgis-testing
Viji V Nair
viji at fedoraproject.org
Sat Dec 4 04:50:50 EST 2010
I am sorry, there is a BIG confusion, here we are talking ONLY about
ELGIS -5. Our ultimate goal is to provide EVERYTHING which is built
around GDAL, any abstraction layer...anything, absolutely no doubt
"The Only issue here is how we can port all these latest GIS app to
ELGIS 5 without doing a major base os upgrade" Which Matheiu want..
On Sat, Dec 4, 2010 at 4:57 AM, Ralph Apel <r.apel at r-apel.de> wrote:
> "need a patched Java"?
> Would you please be more precise?
I am mentioning about the OpenJDK issues
> What is "GDAL with image-io extension"?
> What I know is that
> - there is a GDAL
> - there is an effort (from geosolutions) to connect this upstream GDAL
> to just another but important "abstraction layer" called "image-io"...
We need image-io. For ELGIS 5 we need to have the Sun Java for this,
need to take a call either we include image-io support for EL5 with
Sun Java or Leave the same for EL6 and above
> "no maven"?
> Maven is just another project build environment, certainly a very
> successful one, which has been adopted by almost every upstream OS Java
> So "no maven" means "no Java", right?
> Such a position will not be easy to defend.
Confusion....I am mentioning here about the maven2, this will end up
modifying the base os in EL5. So I would suggest keep maven2 outside
for ELGIS 5.
There is nothing to defend. you, me and the community decides what
need to be there...no one stopping us..i am also just a community
contributor like you ..:), just working for fedora because I like that
> But let's keep constructive:
> Should geotools be packaged? Yes (I suppose)..)
> Should then imageio-ext be packaged? Yes (if you answered yes to above
Yes we should have all of this, but the question is how many of them
can be integrated to EL5 without modifying the base OS
> OK, there are several other, perhaps even more conflicting Requires for
> geotools, should we bother to cope with them? Yes, we should
> (particularly is we [EL] aren't bound to certain limitations distros
> We [EL] SHOULD be be authorized to stalk around and seek for any
> possible solutions to those difficult issues. We would not be able to do
> such if we depend on an authorization from whatever distro...
There is no authorization required, only licensing concerns. We can
package anything we want, but here ELGIS repo should not alter the
base OS. If we are okay with this, there is no one stops us doing
> In short: ELGIS or JPP or whatever should be "upstream" for Fedora, just
> as Fedora is "upstream" for EPEL and EPEL is "upstream" for EL. Let them
> do their work and then, after a work done, talk and then, after having
> talked about, take it or reject it.
Hope this has come out because of the confusion, these package are
there is the rpeo for a purpose, many people around the globe is using
it. It should be made as feature rich as we can.
> This seems to be the same old stuff of centralized v/s decentralized
> steering of goals and projects and so on. Why plan in detail what you
> are delegating?
> This is an interesting (while conflicting) issue on organizing several
> (4,5 or 6 ) levels of "upstreaming" where once Fedora declared itself
> (+- rightfully) to be the only real "upstream". But that is true for
> "horizontal", general purpose stuff. We are now creating a pattern to
> deal with any other "vertical", specialized applications.
> - let "horizontal", general purpose people take care of "horizontal",
> general purpose, contents; that means: ELGIS trying not to fork or keep
> its own versions of xerces or whatever.
> - let "vertical", special purpose people take care of their purpose
> bits; that means: create certain quality measures to help you decide
> whether or not include them into your distro options - but don't pretend
> to be "planning" their work...
> An please remember: GIS is here only a representative case of "some"
> "vertical" matter.
> @Viji: Are we able to cooperate?
In fedora we are including/integrating most bleeding edge versions of
the applications. EL is generally a tested and robust platform. In
many cases they cannot port a latest version of the application to EL
because of the base dependencies. This can be done with a parallel
package in ELGIS with least amount of base os changes.
So, the basic question still remains, which spec file and dependencies
which we use for EL5
Hope we are clear at this point.
> On Thu, 2010-12-02 at 18:35 +0530, Viji V Nair wrote:
>> The GDAL with image-io extension need a patched Java and preferably Sun Java.
>> You have mentioned that you need a clean version, Options are:
>> 1. Complete Clean Version - Regular jnis, no maven2, no sun java, no patching
>> 2. With patch and sun java - no maven
>> Also, have u got a chance to test the gdal-grass plugin?
>> On Thu, Dec 2, 2010 at 5:17 PM, Mathieu Baudier <mbaudier at argeo.org> wrote:
>> > Hi Viji, Ralph,
>> > should I merge the two spec files (the one from Ralph with imageio-ext
>> > and the one from Viji for Fedora) or do we want to have the
>> > imageio-ext stuff first merged into the Fedora spec file?
>> > I can always merge the two (and probably soon will) and that won't be
>> > too hard to synchronize with Fedora later on.
>> > I just wanted to check again.
>> > Cheers,
>> > Mathieu
>> > On Fri, Nov 26, 2010 at 11:25, Mathieu Baudier <mbaudier at argeo.org> wrote:
>> >> This spec file does not contain the imageio-ext build done by Ralph.
>> >> See:
>> >> https://projects.argeo.org/elgis/svn/factory/trunk/rpmbuild/elgis/gdal/SPECS/gdal.spec?r=121
>> >> for the current version.
>> >> Are these imageio parts specific to EL5, or should they also be
>> >> reported to Fedora?
>> >> There is no hurry to answer/solve this. GDAL proper is currently
>> >> usable in testing.
>> >> On Fri, Nov 26, 2010 at 11:00, Viji V Nair <viji at fedoraproject.org> wrote:
>> >>> sorry, missed the attachment.
>> >>> Thanks
>> >>> Viji
>> >>> On Fri, Nov 26, 2010 at 3:28 PM, Mathieu Baudier <mbaudier at argeo.org> wrote:
>> >>>>>> ANOTHER option would be to package the poms and depmap frags into an
>> >>>>>> additional subpackage "gdal-java-poms" or "gdal-java-maven2", sort of
>> >>>>>> "If you want to use gdal-java properly with maven2, you should install
>> >>>>>> gdal-java-maven2, which of course requires maven2". That would be clean.
>> >>>>> I like this.
>> >>>>> If there is a clean way and the only cost is just another small
>> >>>>> package, I find it worth the (little) effort.
>> >>>> But then that would not be a subpackage, but rather a full-fledged
>> >>>> package in elgis-plus.
>> >>>> _______________________________________________
>> >>>> el mailing list
>> >>>> el at lists.osgeo.org
>> >>>> http://lists.osgeo.org/mailman/listinfo/el
>> > _______________________________________________
>> > el mailing list
>> > el at lists.osgeo.org
>> > http://lists.osgeo.org/mailman/listinfo/el
>> el mailing list
>> el at lists.osgeo.org
> el mailing list
> el at lists.osgeo.org
More information about the el