[El] Custom RPM repositories structure

[Mathieu Baudier]

Hello,

I would like to have your opinion on how we should structure the
custom RPM repositories (that is the repositories where we maintain
our GIS packages when those in EPEL are not enough).

I think that there are two dimensions to consider for each package:
A - whether the package requires to update the base EL ('plus' vs.
'extras' to keep the CentOS nomenclature)
B - how new is the package version

I guess that there is not much discussion about A, and that we should
keep packages that require to update base EL in distinct repositories.

With regards to B, the question is: do we always want to have the
latest stable version of a given package?
Or does it make sense to also maintain older ones?

Here are a few examples:

# QGIS
Currently we know how to package v1.0.2 which is their LTS (Long Term
Support) version as well as v1.4.0 (both require a newer version of QT
and thus update base)
Would anybody want to use QGIS v1.0.2 rather than v1.4.0?

# GRASS
Currently we know how to package v6.2.3 as well as v6.4.0RC6 which is
a release candidate for 6.4.
This is a different case since 6.4 is not yet a stable version, so
this should probably rather go to a "-testing" repository (similar to
epel-testing).

This 6.4.0RC6 version works pretty well as far as I could see, but we
have problems with the wxUI interface (see this thread:
http://lists.osgeo.org/pipermail/grass-user/2010-June/056458.html) and
we are currently trying to fix them so that the related fixes could go
into 6.4.

But the question remains: would anybody want to use an older version
of GRASS than the latest stable?
Will it still make sense to maintain a GRASS v6.2 when GRASS v6.4 is out?

# PostGIS
With server/database side components the question is probably more
relevant since the data format may change etc. so an upgrade to the
next stable may have to be done carefully and may depend on other
constraints (esp. if it requires to upgrade PostgreSQL as well).

We currently know how to package:
v1.3.6
v1.4.1
v1.5.1

Would you be interested in having the v1.3.x and v1.4.x being
maintained as well as the latest (v1.5.x)?

#
# A proposal
#
I'm not too keen in having "-stable" and "-unstable" nomenclatures
since we plan to support stable versions only (we can always have
additional "-testing" repositories for... testing, like we currently
do with GRASS) and it implies that, say, PostGIS v1.5.x would be less
stable that v1.3.x which is not our point here.

So, what about the following?
 gis-conservative
 gis-recent
 gis-plus-conservative
 gis-plus-recent
(Other naming ideas are welcome!)

The *-recent repositories would always override (from a version
perspective) the packages in the *-conservative repositories.
Users could chose which ones to activate (same for the *-plus-* repositories).
As new stable version of a package would come out, we would discuss on
this list with which timing we deprecate the version in *-conservative
and move the one in *-recent to  *-conservative.

This leaves open the question of what to do with e.g. PostGIS v1.4.x
(v1.3.x would be in gis-conservative, v1.5.x in gis-recent)
I am not very keen of having packages names postgis13, postgis14,
postgis15, etc. instead of 'postgis' because it makes maintaining the
spec files a bit harder as well as integrating with Fedora/EPEL.
Any ideas?

#
# Required non GIS libraries also in the GIS repositories
#
Currently we have some third parties libraries in the 'argeo-extras'
and 'argeo-plus' repositories, which have nothing to do with GIS but
are required to build the GIS packages, most importantly:
- in argeo-extras: lesstif (for GRASS)
- in argeo-plus: Qt4, cmake, sip, sqlite, PyQt4 (for QGIS)

I plan to move them to this new repository structure (resp. to gis-*
and gis-plus-*), in order to:
- reduce the number of repos to consider, esp. if we increase it with
the above proposal
- have the GIS repositories "self consistent" so that they can easily
be moved to another hosting and do not need to depend on our
repositories where we build non related software

To illustrate the second point: I moved away a rebuild of the OpenJDK
from argeo-plus because users installing QGIS may have then
inadvertently upgraded their base OpenJDK through a yum update!

Many thanks in advance for your comments and feedback on your real-life needs!

Cheers,

Mathieu