[El] Custom RPM repositories structure

Cameron Shorter cameron.shorter at gmail.com
Wed Jun 16 17:06:28 EDT 2010


I suggest that we try to standardise as much as possible on release 
versions and dates between distributions, which in turn should reduce 
work overhead for all the gis projects we are targeting.

For release dates, the OSGeo Live DVD is working on a 6 month cycle, 
driven by the FOSS4G calendar (a major release for foss4g) and a minor 
release 6 months afterwards. This aligns with Ubuntu which puts out 6 
month releases too, with the major release coming out a few months 
before foss4g.

For naming environments, I suggest using terms people are familiar with. 
I'm not sure what redhat uses, but debian/ubuntu use stable, testing and 
unstable:
http://www.debian.org/releases/


On 16/06/10 21:46, Mathieu Baudier wrote:
> 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
> _______________________________________________
> el mailing list
> el at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/el
>    


-- 
Cameron Shorter
Geospatial Director
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
http://www.lisasoft.com



More information about the el mailing list