[mapguide-internals] RE: [fdo-internals] Hosting FDO 3.5 builds / Binaries for CentOS and Ubuntu

[Greg Boone]

Hi All,

One point of interest. Such directory name changes would have to be applied to the trunk. It is too late to get these types of changes applied to the official release of 3.5.0. In that light, we can bump up the proposed directory to fdo-3.6.0 or I am open to suggestions. 

Greg

-----Original Message-----
From: mapguide-internals-bounces at lists.osgeo.org [mailto:mapguide-internals-bounces at lists.osgeo.org] On Behalf Of Trevor Wekel
Sent: Thursday, February 18, 2010 11:23 AM
To: FDO Internals Mail List; MapGuide Internals Mail List
Subject: [mapguide-internals] RE: [fdo-internals] Hosting FDO 3.5 builds / Binaries for CentOS and Ubuntu

Cross posting to mapguide-internals since both projects are impacted...

Ok.  Sounds good.  Is everyone ok with /opt/osgeo/fdo-3.5.0 and /opt/osgeo/mapguide-2.2.0 for install directories?

I dug around a bit looking at .deb and .rpm naming conventions and came up with the following.  "changenum" is the Subversion changeset number for the respective repository.  Differences in "_" and "-" are significant.  Ubuntu/Debian and CentOS/Fedora seem to have slightly different naming conventions.

fdo-[core,sdf,shp,wfs,wms,arcsde,rdbms,gdal,ogr,postgis,kingoracle,sqlite]_3.5.0-changenum_[i386,amd64].deb

fdo-[core,sdf,shp,wfs,wms,arcsde,rdbms,gdal,ogr,postgis,kingoracle,sqlite]-3.5.0-changenum.el5.[i386,x86_64].rpm

The various providers would require an appropriate installation of fdo-core (ie. greater than or equal to the version it was built with).  And for MapGuide,

mapguide-[server,webextensions]_3.5.0-changenum_[i386,amd64].deb
mapguide-[server,webextensions]-2.2.0-changenum.el5.[i386,x86_64].rpm

And MapGuide would also require an appropriate installation of fdo-core (ie. greater than or equal to the version it was built with). 


Regards,
Trevor

-----Original Message-----
From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Jason Birch
Sent: February 18, 2010 8:12 AM
To: FDO Internals Mail List
Subject: Re: [fdo-internals] Hosting FDO 3.5 builds / Binaries for CentOS and Ubuntu

I'd suggest that if you're installing under osgeo (which makes sense to me) that you drop the "opensource" part of "mapguideopensource" as we have on the windows installer.

Jason

On 2010-02-17, Trevor Wekel <trevor_wekel at otxsystems.com> wrote:
> Hi Traian,
>
> I am mostly interested in the binary installer.
>
> Most Linux distributions adhere to the Unix Filesystem Hierarchy 
> Standard
> (FHS) http://proton.pathname.com/fhs/.  According to the standard,
>
>> The /usr/local hierarchy is for use by the system administrator when 
>> installing software locally. It needs to be safe from being 
>> overwritten when the system software is updated. It may be used for 
>> programs and data that are shareable among a group of hosts, but not 
>> found in /usr.
>> No other directories, except those listed below, may be in /usr/local 
>> after first installing a > FHS-compliant system.
>
> So building and then installing Fdo to /usr/local is probably ok but 
> installing to /usr/local/fdo-3.5.0 seems to violate the standard.  
> Using a package manager under /usr/local seems a bit dicey.
>
> /opt may be more appropriate.  According to the standard,
>
>> /opt is reserved for the installation of add-on application software 
>> packages.
>> A package to be installed in /opt must locate its static files in a 
>> separate /opt/<package> or /opt/<provider> directory tree, where 
>> <package> is a name that describes the software package > and 
>> <provider> is the provider's LANANA registered name.
>> Package files that are variable (change in normal operation) must be 
>> installed in /var/opt.
>> Host-specific configuration files must be installed in /etc/opt.
>
> So both /opt/fdo-3.5.0 and /opt/osgeo/fdo-3.5.0 would be legal from a 
> directory usage standpoint.  The /var/opt and /etc/opt requirements 
> would make MapGuide installs more complicated but would not affect Fdo 
> installation.  Maybe we just "ignore" those rules for now and do some 
> additional fix up when time permits.
>
> Actually I think /opt/osgeo/fdo-3.5.0 might be better choice because 
> it leads logically to /opt/osgeo/mapguideopensource-2.2.0 and may also 
> allow simultaneous installation of major releases and service packs.  
> For
> example:
>
> /opt/osgeo/fdo-3.5.0 with /opt/osgeo/mapguideopensource-2.2.0  
> (initial
> release)
> /opt/osgeo/fdo-3.5.2 with /opt/osgeo/mapguideopensource-2.2.1  (sp2 
> for Fdo,
> sp1 for MapGuide)
> /opt/osgeo/fdo-3.6.0 with /opt/osgeo/mapguideopensource-2.3.0  (next 
> major
> release)
>
> Regards,
> Trevor
>
> _______________________________________________
> fdo-internals mailing list
> fdo-internals at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/fdo-internals
>
>
_______________________________________________
fdo-internals mailing list
fdo-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/fdo-internals