[El] Custom RPM repositories structure

Thu Jun 17 15:16:15 EDT 2010

Hello Mathieu:

On 06/16/2010 02:46 PM, 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)
>    
Unless there are enough package maintainers involved, I'd say just stick 
with one version for each software.
> 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?
>
>    
As others have said, I wouldn't even bother with 1.0.2.
> # 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?
>
>    
GRASSS 6.4.0 has been in RC status for over a year and a half. It's 
quite stable enough, and there are enough improvements over 6.2 to make 
it the preferred version.
> # 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!)
>    
These seem overly confusing to me. Wearing the hat of a user, I'd want 
to do a simple "yum install ..." and get what the package maintainer 
considers "stable", like most other software in EL. Taking the example 
of UbuntuGIS there's one version of QGIS, one of GRASS, one of PostGIS, 
etc that you get from that repo.

Regards,
Micha
> 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
>
> This mail was received via Mail-SeCure System.
>
>
>    

-- 
Micha Silver
Arava Development Co. +972-52-3665918
http://surfaces.co.il