[Live-demo] Re: GIS RPMs for Enterprise Linux (RHEL/CentOS/ScientificLinux)
mbaudier at argeo.org
Tue May 4 03:20:35 PDT 2010
Hello Cameron, hello all,
thanks for your nice feedback!
You can see my original mail to Tyler below.
I will detail here the idea, based on your feedback, and suggest how
we could proceed further.
This (long) mail could partly serve as a basis for a project page.
-# OSGeo Live DVD
I was aware of this project (haven't tested it yet) and I think that
this is a great idea!
Ubuntu seems to be the relevant platform indeed, due to its ease of
use (esp. for users not familiar with Linux) and how easy it is to
I personally also use Ubuntu as a GIS platform on non-workstation
hardware (laptop, notebook) and in order to introduce FLOSS GIS to
# Other RPM based distributions
When I packaged some GIS apps for CentOS I came across the efforts
that have been cited (esp. the OpenSUSE one, I think I got inspiration
from some of their spec files at some points. It covers mostly low
level libs though)
As I wrote to Tyler, my idea is to focus on Enterprise Linux and
derivatives (RHEL, CentOS, ScientificLinux) which has its own set
challenges, priorities and constraints. (see below)
There is of course coordination to be done between these projects, and
many things can be shared but I am not talking here of a general "RPM
based distribs" coordination effort.
# Enterprise Linux (EL) for GIS
The main priorities for EL users are in general stability, reliability
Therefore the binary compatibility with the "prominent North-American
Linux vendor" (Red Hat) is a very important issue and cases when the
base distribution needs to be updated have to be clearly identified.
On the other hand, FLOSS GIS is evolving very rapidly currently (you
know this much better than me!) and tracking recent versions of the
software and libraries may be more important than for, say, Apache
HTTPD or MySQL.
Desktop and Server GIS needs also to be approached differently:
- EL distribs are primarily known as server distributions and could be
an excellent and trusted platform for Server GIS deployment
- it can also makes sense for powerful scientific workstations for
computation intensive tasks which are common in Desktop GIS
As Tyler pointed out, serious support for EL would foster FLOSS GIS
acceptance in the enterprise world (including government and
# The EPEL repository
There are already a lot of GIS software in Fedora, many of them ported
to EPEL (Fedora managed repo providing RPMs for EL with the constraint
that they should not update or require to update the base distrib:
Devrim Gündüz, who maintains a lot of the GIS libraries in Fedora and
EPEL (and also an excellent PostgreSQL RPM repo:
http://yum.pgrpms.org/) wrote to me that he would need some help with
I therefore think that all libraries that can easily be maintained in
EPEL should be maintained there when possible, following their
policies: EPEL is a very trusted repo since it is considered as a
quasi official Red Hat repo.
# Additional repository
However, sometimes is it needed to upgrade the base distrib.
My most challenging package so far was QGIS: it required me to rebuild
cmake, sqllite and ... Qt4.
I do not regret since I really like QGIS as a powerful "swiss army
knife". And once this work had been done on their LTS version
(v1.0.2), it was very easy to build and package v1.4.0.
Another issue was PostGIS whose recent versions require a newer
version of PostgreSQL than what was available in EL 5.4 (RHEL 5.5 now
ships with PostgreSQL 8.4, CentOS 5.5 is due very soon) and I had to
use Devrim's repo.
Flexibility is required because sometime people could technically
upgrade, say, PostGIS but they don't want because their apps would
break due to query language changes.
On the other hand, people starting a new project in general want to
start with the latest stable version of such components (precisely
because they know that upgrade will be painful later).
A solution could be to provide (incompatible) postgis13, postgis14,
postgis15 etc. packages
=> this is not the approach a distribution would take, but the idea
here would be to have a community effort to provide this flexibility.
Otherwise, in the end everybody repackage it own RPMs on a case by
case basis which makes it harder to track bug-fix/security updates
etc. (low level libraries like GEOS or GDAL are not that difficult to
build and package)
# Concretely, what could usefully be done in OSGeo
- act as a central point for information about the various EL related
activities in the GIS field, with links, How-Tos etc.
=> a wiki page would be enough to start with I guess
- provide an additional RPM repo for use when EPEL is not enough.
This would typically be based on the proof of concept I have done so
far (see below) and inputs from those many people who rebuild their
own RPMs. In general, nothing more is required than to rebuild Fedora
RPMs. When EL 6 would be released this will be very easy for a while
since it will be very close from Fedora.
=> this would imply somewhere to version the spec files
=> and a community driven procedure for updating the repo: you cannot
just update an EL repo like that if you want people to rely on it for
enterprise activities. Announcements for each package update could
make sense as Red Hat (and CentOS) do.
=> I would support being consistent with the versions of the Debian
GIS (and thus Ubuntu GIS) project: people should be able to switch
from one distrib to the other while using teh same software stack, and
thus the same data
No need to say that it would be great to collaborate with other
efforts in OSGeo such as the LiveDVD or Ubuntu GIS: there are plenty
of issues which are probably not
distrib specific and, as Cameron pointed out, you have done a lot of
I'm far from being a packaging expert or even a Linux specialist.
I am primarily a Java developer.
This packaging effort for GIS on EL was my first real activity in this
field (I also package recent versions of the Java OpenJDK for use in
So, there are probably people around with much more experience and
that would be great to have them on board (I'm thinking of Devrim for
# Next steps
I'll be traveling to Ukraine and Moldova next week and the week after,
partly to test cartography/GIS tools on the field (maps
corrections/addons to be contributed to OSM of course...), testing the
Linux GIS stack on Atom hardware (we'll use Ubuntu for that, just for
a question of managing the small screen).
But by the end of this month (May 2010), I'll be available to bring
In between we can continue to discuss this here and maybe also on the
general discuss list at some point, as Tyler suggested?
I hope that we will be able put such a community effort in place!
# EL GIS packaging proof of concept, current status
* Requiring no changes in the base distribution (depends on EPEL)
- gdal (1.6.3)
- geos (3.2.0)
- grass (6.2.3 and 6.4.0RC6)
- mapserver (5.6.0)
- postgis (1.3.6)
- proj (4.7.0)
* Requiring changes in the base distribution (depends on EPEL,
PostgresqlRPM and Argeo Plus)
- qgis (1.0.2 and 1.4.0)
- postgis (1.4.1 and 1.5.1)
On Mon, May 3, 2010 at 22:12, Cameron Shorter <cameron.shorter at gmail.com> wrote:
> Hello Mathieu,
> Tyler, thanks for the introduction.
> As Tyler mentioned, the OSGeo Live DVD project builds a LiveDVD based upon
> an Xubuntu system.
> Of value to you, is that project leads have written, and continue to
> maintain, bash install scripts for ~ 35 GIS packages, which should make it
> much easier to build RPMs.
> Details about the project are at: http://wiki.osgeo.org/wiki/Live_GIS_Disc
> I suggest following links to our build process, list of projects and
> contacts, and our svn.
> At the moment, I'm writing up the OSGeo marketing pipeline, and defining
> what is required from Geospatial projects to help OSGeo promote them. Once
> your RPM project kicks off, I suggest adding your details in here.
> Of particular note:
> * We wish to make it as easy as possible for projects to contribute to
> marketing/packaging efforts as possible. So any sharing we can do between
> packaging efforts would be great. (Eg, lets share Definition files,
> documentation files, examples etc)
> Tyler Mitchell (OSGeo) wrote:
>> Hello Mathieu,
>> Thank you for writing! Indeed if it can be coordianted through OSGeo, I
>> think it would be highly successful. I think the place it is being
>> discussed the most is through our live dvd creation (ubuntu based) project.
>> I'm cc'ing Alex and Cameron to get their thoughts on whether the livedvd
>> project is where it should be discussed or not.
>> Aside from that, I think many people on our main "discuss" mailing list
>> would be very interested. There may have been some movement on the topic
>> already and your note might help bring them all together.
>> I can help support you by creating a mailing list when needed (if enough
>> people on discuss are interested) and by helping connect you to specific
>> people I know might care.
>> Personally, having packages ready for RHEL is critical for further
>> enterprise penetration, so will help in guiding you as best I can.
>> On 05/01/2010 05:17 AM, Mathieu Baudier wrote:
>>> (I found your mail on the OSGeo contact page, this message was to long
>>> to be sent via the form)
>>> it has been a few months that we are working on packaging the latest
>>> stable versions of some useful GIS libraries and software for CentOS 5
>>> (see below for details).
>>> The goal is to have a solid but up to date GIS stack for the desktop
>>> as well as the server under RHEL/CentOS/ScientificLinux (we tested
>>> only CentOS so far).
>>> Most of the effort consisted in rebuilding/repackaging recent Fedora
>>> SRPMs, some being more difficult than others because of the older
>>> libraries included in RHEL 5.
>>> We looked closely at the Debian GIS project (and the related Ubuntu
>>> GIS project) and are more or less tracking their versions. One goal is
>>> to be able to switch quickly from one distribution to the other while
>>> using the same GIS software stack.
>>> We already had some informal contacts with community members who
>>> contributed RPM spec files.
>>> After having tested the approach for a few months and with RHEL 6
>>> around the corner (the beta is already available), we would like to
>>> see how to contribute this effort to the community and make it
>>> something more public and shared (and thus more useful for everybody).
>>> In http://wiki.osgeo.org/wiki/OSGeo_Binary_Distribution you say that
>>> there is currently no centralized effort in the RPM community.
>>> Our idea would to focus on Enterprise Linux derivatives and to
>>> centralize knowledge and approaches (not just provide RPMs).
>>> In addition we could maintain and provide a set of RPMs when needed,
>>> based on what we have done already.
>>> There are already efforts going on in this field and we want to
>>> synchronize with them, not duplicate what they are doing:
>>> - a Fedora SIG: http://fedoraproject.org/wiki/GIS
>>> - the EPEL repository: https://fedoraproject.org/wiki/EPEL
>>> - PostgreSQL for Enterprise Linux: http://yum.pgrpms.org/
>>> The problem with the EPEL is that they cannot include software which
>>> requires to upgrade the base system.
>>> For those packages who don't require upgrades of the core, the best
>>> solution would be to maintain up to date versions there (we already
>>> had contacts with EPEL maintainers).
>>> But sometime more flexibility is needed, e.g. for PostGIS, people
>>> sometimes don't want to upgrade from 1.3 to 1.5 because of language
>>> changes, even if if woudl be possible.
>>> OSGeo seems the best place to centralize this effort, would you be
>>> Best regards,
>>> Mathieu Baudier
>>> * Requiring no changes in the base distribution (depends on EPEL)
>>> - gdal (1.6.3)
>>> - geos (3.2.0)
>>> - grass (6.2.3 and 6.4.0RC6)
>>> - mapserver (5.6.0)
>>> - postgis (1.3.6)
>>> - proj (4.7.0)
>>> * Requiring changes in the base distribution (depends on EPEL,
>>> PostgresqlRPM and Argeo Plus)
>>> - qgis (1.0.2 and 1.4.0)
>>> - postgis (1.4.1 and 1.5.1)
> Cameron Shorter
> Geospatial Solutions Manager
> Tel: +61 (0)2 8570 5050
> Mob: +61 (0)419 142 254
> Think Globally, Fix Locally
> Geospatial Solutions enhanced with Open Standards and Open Source
More information about the Osgeolive