[El] Announce: New structure and location for the ELGIS RPM repositories

[Mathieu Baudier]

Hello,

following our recent discussions, I set up a new repository structure
from scratch and rebuilt all custom packages.

The main goals were:
- to put in place the approach discussed on this list (stable and
testing, one package version per repo)
- to remove all dependencies to Argeo's repositories and replace
references to Argeo by ELGIS in packages (%dist .el5.argeo becomes
%dist .el5.elgis)
- have stable URLs for the time to come

It is located here:
http://elgis.argeo.org/

There is a minimal documentation with package lists and installation
instructions.
It is pointing to the Wiki page where I think we should centralize the
knowledge (and that I will update very soon in order to reflect these
changes).

This being said here are bit more details:

# Repositories

elgis: stable packages which do not require to update the base system
elgis-plus: stable packages which do require to update the base system
elgis-testing: latest packages which do not require to update the base system
elgis-plus-testing: latest packages which do require to update the base system

The naming follows a mix of CentOS (-plus) and EPEL (-testing) naming
conventions.
>From a Debian perspective: elgis[-plus] is "stable" and
elgis[-plus]-testing is "testing".

Please note that these repositories do not depend on argeo-extras and
argeo-plus anymore: I have rebuilt and integrated in ELGIS repos the
packages which are not strictly GIS but are required by some of the
GIS packages (e.g. lesstif in elgis and qt4, PyQt4, etc. in
elgis-plus).

# Build process

The specs files, patches, scripts etc. used are available in an ELGIS
dedicated Subversion repository:
elgis[-plus]-testing : https://projects.argeo.org/elgis/svn/factory/trunk/
elgis[-plus] : https://projects.argeo.org/elgis/svn/factory/branches/5-stable/

I will update the instructions on the Wiki on how to build locally,
but they haven't changed much.

In order to automate the process we use our SLC system which basically
generates some files and make system calls in order to:
- download the sources
- generate an SRPM
- call mock on it
- and then generate the repositories metadata.
But all that is really needed to build locally (spec files and
patches) is already in the Subversion repository.

# Hosting, infrastructure, URLs

The repositories are built remotely and hosted in the new
infrastructure that we are currently putting in place.
We are in a transition phase and this new infrastructure is not yet
considered as in production (although the part related to ELGIS is in
beta testing and continuously available).

Therefore:
- I apologize in advance if there should be some glitches (note that
the old location on the current infrastructure will stay available)
- the certificate used to protect the subversion repository is
currently self-signed, that will change in the next few months
- we will wait until September / October before we can widely
communicate about the repository (e.g. announcements on CentOS /
Scientific Linux mailing-list, etc.). Until then, thanks in advance
for your feedback!

# Next steps

So, to summarize, we now have repositories which are consistent and
self-contained.
If at some point it is decided to move to another
hosting/infrastructure, this will just be a matter of
dumping/reloading the Subversion repository and changing the URLs.

The stable repository is a strict rebuild of the current state. I have
tested postgis pretty extensively over the last few days as well as
QGIS.
The testing repository contains only GDAL 1.7.2 which has been
recently contributed (I tested it quickly on my local workstation via
QGIS).

I would suggest that we keep the stable repository with the current
minor versions for the time being (until, say, EL 5.6) and just apply
bug fixes / security updates (as done recently for mapserver).
We can push new versions (like GDAL 1.7.2) to elgis-testing and work
with them, they will then "upgrade" to stable at some point.

EL 6 will probably come soon, which will lead to a de-multiplication
of the repositories. Hopefully the process would have become really
smooth and fully automated by then.

I'll be at FOSS4G in Barcelona, maybe I will get the chance to meet
some of you personally.

Many thanks for your comments and ideas during this discussion!
More of them about these new steps are of course welcome.

Cheers,

Mathieu

PS: I tried a bit to build QGIS 1.5 but ran into issues with Python
(Python 2.4 seems too old). It will require a bit of work to have
SIP/PyQt4/QGIS using python-26 provided by EPEL. I'll come back to
this again in September, but don't hesitate to have a look and share
your thoughts about it.