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

[Trevor Wekel]

Hi everyone,

I did some testing with /opt/osgeo this afternoon.  The Ubuntu package checker (lintian) throws an error basically stating that packaged binaries should not be installed to /opt.  I think the only way make lintian "truly" happy is to install directly under /usr.  However, /usr/fdo-3.5.0 is non-standard so we would have to install piecewise underneath the various parts of /usr, ie. /usr/lib/fdo-3.5.0, /usr/doc/fdo-3.5.0, /usr/include/fdo-3.5.0, etc.  That would be a non-trivial change to the build process.

At this point, I agree with Greg.  We should just stick with /usr/local/fdo-3.5.0 for this release.  By "packaging" standards, it is wrong but I am not keen on making significant changes to the automake and/or cmake build process.  We can look at it for Fdo 3.6.

Regards,
Trevor


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:05 PM
To: FDO Internals Mail List
Subject: Re: [mapguide-internals] RE: [fdo-internals] Hosting FDO 3.5 builds / Binaries for CentOS and Ubuntu

A bit confused on why it's too late to change the directory structure for the 3.5 release.  Does the location that it is installed to have the potential to affect the stability of FDO?

If the concern is that there are other products that are counting on the current install location of fdo under Linux, then there's certainly the option for those products to have their own builds of FDO.  We could even create a custom branch / sandbox for this purpose if desired, but I don't think that this should constrain us from making this kind of change.  I don't think we've even started the beta process yet?

Jason
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/fdo-internals/attachments/20100218/fad51d46/attachment.html