[El] Custom RPM repositories structure

[Mathieu Baudier]

So, apparently we are going in the direction of having fixed releases.
>From a packager point of view, this will probably be much easier to manage.
With this approach, I'm also for 'stable' / 'testing' like in Debian.

As Cameron already suggested in one of the preparatory discussions,
these releases could track RHEL/CentOS minor updates (e.g. 5.4 to
5.5): although a lot of compatibility is preserved we have seen with
the 5.5 release that it still has an impact (with the introduction of
PostgreSQL 8.4, PostGIS 1.4 and 1.5 do not require to up=grade base
anymore)

> would it make sense, that to make different repositories for each major
> version?

Do you mean each RHEL/CentOS version? (like 5.4, 5.5 etc.)
That is actually what I did when upgrading to 5.5.

I rebuilt the latest version of each package against CentOS 5.5:
http://www.argeo.org/linux/argeo-el/5.5

and created a link so that it appears as:
http://www.argeo.org/linux/argeo-el/5

while keeping all the RPMs and SRPMs of our previous effort on 5.4
(including the ones that you, Peter, provided, and which kicked off
this project... time to give you credit for that!):
http://www.argeo.org/linux/argeo-el/5.4

So if you would configure your repo file to point to this URL you
could still work on teh older version.

Is it what you mean or could you elaborate with more details on what
you would like to have?
This is most probably easily feasible.

> su -c 'rpm -Uvh
> http://<repo_server>/<repo_path>/elgis-release-2010-04.noarch.rpm'

We can also de-correlate from EL releases and upgrade more often, but
these releases tend to be every 6/9 months or so, don't they?
(we would of course continuously provide releases of the libraries
within a given branch e.g. PostGIS 1.5.1, 1.5.2, etc.)

>> # QGIS
> Personally speaking: no, I use 1.4 and appreciate the newer feature set.
> But I agree that this is in some way in opposition to the "enterprise ==
> stable" equation.
>> # GRASS
> Indeed, GRASS is the only package, where we install a not officially
> stable package, but 6.4 has some thing that we rely on.

Maybe we could have a slightly more aggressive approach with GIS
desktop packages and keep recent versions? (with maybe a qgis-lts
package along a qgis package)
A crash of QGIS doesn't have the same consequences as a crash of
PostGIS I guess...