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

[Zac Spitzer]

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