[El] Custom RPM repositories structure

Peter Hopfgartner peter.hopfgartner at r3-gis.com
Thu Jun 17 06:55:26 EDT 2010


On Thu, 2010-06-17 at 12:31 +0200, Mathieu Baudier wrote:
> 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.
> 
Honestly, I meant major upgrades to MapServer and PostGIS, but now I'm
thinking that syncing with RHEL/CentOS is the smarter choice.
> 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.
> 
I would say that this a good approach and keeps thinks also simple in
terms of "I'm running Red Hat/CentOS n.m, which version of your repo
should I use".
> > 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.)
> 
I've always found the EL release cycles to be very reasonable.
> >> # 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...

I completely agree, as far as QGIS is concerned. For GRASS, we use it on
our servers, too. But this is not a major issue.

Regards,

Peter

-- 
Dott. Peter Hopfgartner

R3 GIS Srl - GmbH
Via Johann Kravogl-Str. 2
I-39012 Meran/Merano (BZ)
Email: peter.hopfgartner at r3-gis.com
Tel. : +39 0473 494949
Fax  : +39 0473 069902
www  : http://www.r3-gis.com

XING : http://www.xing.com/go/invita/8917535



More information about the el mailing list