<HTML>
<HEAD>
<TITLE>Re: [El] Some thoughts on cooperation [SEC=UNCLASSIFIED]</TITLE>
</HEAD>
<BODY>
<FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'>My interpretation of where we are with this thread is that:<BR>
<BR>
</SPAN></FONT><UL><LI><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'>ELGIS could be considered the ‘stable’ version of the repository; and <BR>
</SPAN></FONT></UL><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'><BR>
</SPAN></FONT><UL><LI><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'>FedoraGIS could operate as the development/test/unstable branch.<BR>
</SPAN></FONT></UL><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'><BR>
(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).<BR>
<BR>
If this is the case, then:<BR>
<BR>
</SPAN></FONT><UL><LI><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'>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?
</SPAN></FONT><LI><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'>This could cause an issue for organisations getting access to later stable versions of software which support say newer versions of OGC Services.
</SPAN></FONT><LI><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'>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?<BR>
</SPAN></FONT></UL><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'><BR>
<BR>
Bruce<BR>
<BR>
<BR>
<BR>
On 18/11/10 8:37 PM, "Mathieu Baudier" <<a href="mbaudier@argeo.org">mbaudier@argeo.org</a>> wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'>Hi,<BR>
<BR>
thanks a lot Peter for launching this discussion!<BR>
I think that this was indeed the last step to go through before we<BR>
communicate more widely about our effort: the cooperation with Fedora<BR>
and EPEL.<BR>
<BR>
Here are my thoughts on it (taking also into account the discussion<BR>
around gadal/imageio-ext with Ralph):<BR>
<BR>
- I fully agree that it is easier and beneficial for everyone if<BR>
Fedora is in general the source for RPM packaging.<BR>
<BR>
This is actually what we are already doing in most cases.<BR>
You may have noticed that I recently published some packages with such<BR>
versions <software version>-<number1>_<number2> (e.g. gdal-1.7.2-5_3).<BR>
The <number1> is the build id in Fedora, the <number2> is an<BR>
additional id following the modifications required to get it to work<BR>
on EL.<BR>
I did not want to increase <number1> in order to avoid going "faster"<BR>
than Fedora packaging.<BR>
This is just a tentative approach, but it illustrates the importance<BR>
of Fedora as a source.<BR>
<BR>
- as you all know, the ELGIS repo requires the EPEL repo.<BR>
So, if recent versions of GIS software can be maintained in parallel<BR>
in Fedora and EPEL, we can simply remove them from ELGIS and<BR>
everything will work seamlessly.<BR>
If at some point, EPEL prefers to be more conservative, ELGIS can take<BR>
over and provides more up to date versions.<BR>
<BR>
Personally, this is the approach I would like us to follow from the<BR>
beginning for RHEL/CentOS 6:<BR>
* by default packages are maintained in Fedora and EPEL, we help as<BR>
much as we can<BR>
* except for the ones requiring to upgrade base (but there will be<BR>
very few (none?) of them at the beginning), which will be in ELGIS<BR>
Plus<BR>
<BR>
- this is all well and good and I think that we are all broadly in<BR>
line, but I should also talk about where it itches a bit in order to<BR>
be perfectly honest:<BR>
<BR>
* in order to maintain packages in Fedora/EPEL you need to follow<BR>
guidelines, procedures, use certain build tools, etc. This is of<BR>
course required by such huge projects, maintaining hundred of<BR>
packages. But in order to maintain around 20 GIS packages, I prefer to<BR>
be flexible and informal, discussing packaging decisions via a<BR>
mailing-list as we currently do (noting longer term issues in our Trac<BR>
instance on OSGeo). I'm personally a Java developer who wants a stable<BR>
underlying GIS platform: the amount of energy I can invest in RPM<BR>
packaging is limited, and this is not my main focus.<BR>
<BR>
* I used Fedora during many years. This is a fantastic project, with<BR>
great benefits for the innovation in the free software field. But for<BR>
the reasons above, I simply don't have time/interest for working with<BR>
it and track all updates and the short support cycle. That's why I<BR>
switched to CentOS. So, in other words, I personally won't bother to<BR>
test software on Fedora (exceptions are possible, and I always have a<BR>
Fedora around in a virtual machine, but you see the idea): I just want<BR>
the software to work on RHEL/CentOS.<BR>
<BR>
Feel free to keep the ball rolling!<BR>
<BR>
Cheers,<BR>
<BR>
Mathieu<BR>
<BR>
On Thu, Nov 18, 2010 at 09:10, Peter Hopfgartner<BR>
<<a href="peter.hopfgartner@r3-gis.com">peter.hopfgartner@r3-gis.com</a>> wrote:<BR>
> There seems to be quite some movement in the GIS/RPM world recently.<BR>
><BR>
> 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.<BR>
><BR>
> 1 Fedora Linux<BR>
> 2 EPEL<BR>
> 3 Frank Warmerdam's FWTools<BR>
> 4 Enterprise Linux GIS<BR>
><BR>
> 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<BR>
><BR>
> Fedora Linux GIS: provide up to date OS GIS packages for current Fedora distributions<BR>
> EPEL: provide OS GIS packages for Enterprise Linux, both stable as of software capability and as of software version<BR>
> 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<BR>
> 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.<BR>
><BR>
> Basically, with thess goals, there is a reason to exists more then 1 repo.<BR>
><BR>
> 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:<BR>
><BR>
> 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.<BR>
><BR>
> Peter Hopfgartner<BR>
><BR>
> R3 GIS Srl - GmbH<BR>
> <a href="http://www.r3-gis.com">http://www.r3-gis.com</a><BR>
><BR>
><BR>
> _______________________________________________<BR>
> el mailing list<BR>
> <a href="el@lists.osgeo.org">el@lists.osgeo.org</a><BR>
> <a href="http://lists.osgeo.org/mailman/listinfo/el">http://lists.osgeo.org/mailman/listinfo/el</a><BR>
><BR>
_______________________________________________<BR>
el mailing list<BR>
<a href="el@lists.osgeo.org">el@lists.osgeo.org</a><BR>
<a href="http://lists.osgeo.org/mailman/listinfo/el">http://lists.osgeo.org/mailman/listinfo/el</a><BR>
<BR>
</SPAN></FONT></BLOCKQUOTE>
</BODY>
</HTML>