[fdo-internals] Hosting FDO 3.5 builds / Binaries for CentOS and
jason at jasonbirch.com
Thu Feb 18 00:24:15 EST 2010
Yeah, I'd personally prefer to see the registry as a folder which
contains provider snippets in their own files, or a command-line
utility for registering/deregistering providers. But this has come up
On 2010-02-17, Helio Chissini de Castro <helio at kde.org> wrote:
> On Wednesday 17 February 2010 22:29:03 Trevor Wekel wrote:
>> Does Linux have a /usr/lib64 in addition to a /lib64?
> Yep, /usr/lib64 and /usr/local/lib64 is the standard in at least Mandriva
> Fedora/RedHat for 64 bits
>> Are you still building to /usr/local? From my Ubuntu work, installing
>> packages to /usr/local seems to be a bit of a no-no. The Ubuntu lintian
>> tool generate a whole whack of errors when I try to target /usr/local.
> The cmake build allows you to build in /usr if you want, just need pass a
> different install prefix in cmake commmand line.
> The reason why i'm making /usr/local default is follow the old install place
> making easy for mapguide looking for.
>> Do we want to break each provider out into a separate install package (rpm
>> on Fedora/CentOS, deb on Ubuntu/Debian)?
> I did, but is up to packager choice. There's a simple reason behind this
> effective which is the no need to install a mysql when you just need the
> postgis provider, or unixodbc libraires when you need just the dhp provider.
> There's one issue in split tough, the providers.xml file is not "flexible"
> as a
> point to add/remove new providers entry instaling or not. I'm thinking in a
> xml parser in trigger on post/postun of each package, but would ugly as
> Helio Chissini de Castro
> South America and Brazil Primary Contact
> KDE Developer since 2002
> fdo-internals mailing list
> fdo-internals at lists.osgeo.org
More information about the fdo-internals