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

[Trevor Wekel]

Hi Zac,

To put FDO directly under /usr we would have to modify the build structure.  We currently have

/usr/local/fdo-3.5.0/
   include/
      Common/
      ExpressionEngine/
      Fdo/
      Fdo.h
   lib/
      com/
      libFDO-3.5.0.so
      libExpressionEngine-3.5.0.so

To be compatible with installation under /usr, we would have to generate

/usr/
   include/
      fdo-3.5.0/
         Common/
         ExpressionEngine/
         Fdo/
         Fdo.h
   lib/
      fdo-3.5.0/
         com/
         libFDO-3.5.0.so
         libExpressionEngine-3.5.0.so

In addition, "docs" and "nls" are incompatible with /usr/ so we would have to place these files elsewhere - probably under /usr/share/fdo-3.5.0 and /usr/man/(something).  As far as I know, "nls" contains localized error messages used by the FDO code base so code changes would be required if we move these files around. 

Simply changing the build prefix to /usr would give us

/usr/
   fdo-3.5.0/
      include/
      lib/

which is not *really* correct.  If you look at /usr on a Linux distro you will see /usr/kerberos and /usr/X11R6.  These are software packages like FDO.  However, these packages reside under /usr for historical reasons.  New packages should install to directories underneath /usr/include and /usr/lib.

We could create symlinks using a post install script to map /usr/include/fdo-3.5.0 to usr/local/fdo-3.5.0/include and map /usr/lib/fdo-3.5.0 to /usr/local/fdo-3.5.0/lib.  However, we would have to modify all of the current automake/cmake scripts to generate the correct /usr/ structure initially.  This could be a hassle when dealing with a dozen or so providers.

Furthermore, I do not know if symlinks are a perfect replacement for .so files.  For example, some of the Debian/Ubuntu utilities for creating packages get cranky when a symlink is used instead of a real .so.

Eventually, I think we should install under /usr/lib and /usr/include.  However, I think there will be a number of implementation gremlins lurking around that we will have to resolve.  I think the MapGuide and Fdo teams already have enough work on (our) plates just getting automated 32 bit and 64 bit MapGuide and Fdo builds working and packaged over the next few weeks/months.

So yes, we should do this.  But not yet.

Regards,
Trevor

-----Original Message-----
From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Zac Spitzer
Sent: February 19, 2010 8:02 PM
To: FDO Internals Mail List
Subject: Re: [mapguide-internals] RE: [fdo-internals] Hosting FDO 3.5 builds / Binaries for CentOS and Ubuntu

um couldn't we just do it the proper way and use some symlinks for
backwards compatibility?

On Sat, Feb 20, 2010 at 6:41 AM, Greg Boone <greg.boone at autodesk.com> wrote:
> Creating an "build" and/or an "install" directory sounds fine, as does
> creating a ticket to track the changes.
>
>
>
> As for attaching the files, I am sure people can do the review once the
> files are checked in.
>
>
>
> Greg
>
>
>
> From: fdo-internals-bounces at lists.osgeo.org
> [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Trevor Wekel
> Sent: Friday, February 19, 2010 2:17 PM
> To: FDO Internals Mail List
> Subject: RE: [mapguide-internals] RE: [fdo-internals] Hosting FDO 3.5 builds
> / Binaries for CentOS and Ubuntu
>
>
>
> Hi Greg,
>
>
>
> I have some build/support scripts for creating Ubuntu .deb files almost
> ready to go.  The scripts automatically generate the file lists for the core
> Fdo libraries and the various providers.  These file lists are then fed to
> another set of scripts which create Ubuntu "deb" packages.
>
>
>
> Currently, I have the scripts sitting under a "build" directory.  The
> scripts also create temporary directories for package building in the same
> place.  I would like to check all of these scripts into Subversion.  There
> are a total of four core scripts and a few helper scripts.
>
>
>
> Can I create an "install" folder at the root of the Fdo 3.5.0 tree to house
> the scripts?  I can attach the scripts to a Ticket before submitting if
> someone wants to review a whole bunch of bash trickiness before I submit.
>
>
>
> Regards,
> Trevor
>
>
>
> From: fdo-internals-bounces at lists.osgeo.org
> [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Greg Boone
> Sent: February 19, 2010 10:00 AM
> To: FDO Internals Mail List
> Subject: RE: [mapguide-internals] RE: [fdo-internals] Hosting FDO 3.5 builds
> / Binaries for CentOS and Ubuntu
>
>
>
> Hi Jason,
>
>
>
> I am hesitant to make this change to the 3.5.0 code stream for a number of
> reasons:
>
>
>
> 1)      A beta was posted to the downloads site and I am working on an RC.
> Hopefully one will be posted next week
>
> a.       I do expect that the RC and possibly the final release build will
> be complete before all the bugs are worked out of this new centralized build
> and install process.
>
> b.      I guess I am generally being cautious here. I prefer to stick with
> what we know works instead of trying to fit it in with possible unknown side
> effects.
>
> 2)      We actually have build and runtime code that uses
> /usr/local/fdo-3.5.0 as a default install location. If we change this to
> another directory, we should perform additional testing to determine if we
> have not broken anything
>
> 3)      We have clients that have done extensive testing with 3.5.0 using
> the /usr/local/fdo-3.5.0 directory as a default. I would not want them to be
> asked to redo that testing at this stage in the release cycle.
>
>
>
> Greg
>
> _______________________________________________
> fdo-internals mailing list
> fdo-internals at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/fdo-internals
>
>



-- 
Zac Spitzer
Solution Architect / Director
Ennoble Consultancy Australia
http://www.ennoble.com.au
http://zacster.blogspot.com
+61 405 847 168
_______________________________________________
fdo-internals mailing list
fdo-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/fdo-internals