[El] Some thoughts on cooperation [SEC=UNCLASSIFIED]

Bruce Bannerman B.Bannerman at bom.gov.au
Thu Nov 18 22:11:36 EST 2010


My interpretation of where we are with this thread is that:


 *   ELGIS could be considered the 'stable' version of the repository; and


 *   FedoraGIS could operate as the development/test/unstable branch.

(sorry for using Debian terminology, I'm new to RHEL and related distributes and require RHEL for our work environments. I'm more familiar with Debian deivatives).

If this is the case, then:


 *   How often is it proposed to update the RHEL ELGIS packages? Once every two years (excluding bug fixes) to keep in line with RHEL releases?
 *   This could cause an issue for organisations getting access to later stable versions of software which support say newer versions of OGC Services.
 *   Is there a concept with RHEL Packaging similar to Debian's Backports where newer versions of software are backported to work with the Stable release of Debian?


Bruce



On 18/11/10 8:37 PM, "Mathieu Baudier" <mbaudier at argeo.org> wrote:

Hi,

thanks a lot Peter for launching this discussion!
I think that this was indeed the last step to go through before we
communicate more widely about our effort: the cooperation with Fedora
and EPEL.

Here are my thoughts on it (taking also into account the discussion
around gadal/imageio-ext with Ralph):

- I fully agree that it is easier and beneficial for everyone if
Fedora is in general the source for RPM packaging.

This is actually what we are already doing in most cases.
You may have noticed that I recently published some packages with such
versions <software version>-<number1>_<number2> (e.g. gdal-1.7.2-5_3).
The <number1> is the build id in Fedora, the <number2> is an
additional id following the modifications required to get it to work
on EL.
I did not want to increase <number1> in order to avoid going "faster"
than Fedora packaging.
This is just a tentative approach, but it illustrates the importance
of Fedora as a source.

- as you all know, the ELGIS repo requires the EPEL repo.
So, if recent versions of GIS software can be maintained in parallel
in Fedora and EPEL, we can simply remove them from ELGIS and
everything will work seamlessly.
If at some point, EPEL prefers to be more conservative, ELGIS can take
over and provides more up to date versions.

Personally, this is the approach I would like us to follow from the
beginning for RHEL/CentOS 6:
* by default packages are maintained in Fedora and EPEL, we help as
much as we can
* except for the ones requiring to upgrade base (but there will be
very few (none?) of them at the beginning), which will be in ELGIS
Plus

- this is all well and good and I think that we are all broadly in
line, but I should also talk about where it itches a bit in order to
be perfectly honest:

* in order to maintain packages in Fedora/EPEL you need to follow
guidelines, procedures, use certain build tools, etc. This is of
course required by such huge projects, maintaining hundred of
packages. But in order to maintain around 20 GIS packages, I prefer to
be flexible and informal, discussing packaging decisions via a
mailing-list as we currently do (noting longer term issues in our Trac
instance on OSGeo). I'm personally a Java developer who wants a stable
underlying GIS platform: the amount of energy I can invest in RPM
packaging is limited, and this is not my main focus.

* I used Fedora during many years. This is a fantastic project, with
great benefits for the innovation in the free software field. But for
the reasons above, I simply don't have time/interest for working with
it and track all updates and the short support cycle. That's why I
switched to CentOS. So, in other words, I personally won't bother to
test software on Fedora (exceptions are possible, and I always have a
Fedora around in a virtual machine, but you see the idea): I just want
the software to work on RHEL/CentOS.

Feel free to keep the ball rolling!

Cheers,

Mathieu

On Thu, Nov 18, 2010 at 09:10, Peter Hopfgartner
<peter.hopfgartner at r3-gis.com> wrote:
> There seems to be quite some movement in the GIS/RPM world recently.
>
> As by now, there are at least 4 sources for RPM packages within RHEL/CentOS/Fedora, not to mention Mandrake, which has excellent GIS support and SuSE, which I do not know much about.
>
> 1 Fedora Linux
> 2 EPEL
> 3 Frank Warmerdam's FWTools
> 4 Enterprise Linux GIS
>
> One question that arises is if we could reduce the number of sources for GIS rpm packages. I think, that this depends on the goals of each project. In my understanding, but I would ask each party to speak up for themself, the goals could be
>
> Fedora Linux GIS: provide up to date OS GIS packages for current Fedora distributions
> EPEL: provide OS GIS packages for Enterprise Linux, both stable as of software capability and as of software version
> FWTools: I guess that at the time Frank was working on it it was a pioneering work of packaging quality OS GIS software into rpm
> EL-GIS: proide stable software, as of software capability, but upgrade with caution the versions, in order to have up to date GIS software available for Enterprise Linux.
>
> Basically, with thess goals, there is a reason to exists more then 1 repo.
>
> The next question could be: could we benefit from each other? I do think so. If the goals are similar to what I speculated, a proposal might be:
>
> We join forces to provide high quality GIS packages within Fedora GIS. EL-GIS packages will be derived with those Fedora packages, maybe with the minimum adaption needed to adapt them to the older software on the Enterprise platform (as might be Python, QT, Boost etc.). Basically, Fedora GIS will become the upstream for the packages.
>
> Peter Hopfgartner
>
> R3 GIS Srl - GmbH
> http://www.r3-gis.com
>
>
> _______________________________________________
> el mailing list
> el at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/el
>
_______________________________________________
el mailing list
el at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/el

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/el/attachments/20101119/731c7123/attachment.html


More information about the el mailing list