I would like to comment this.
I think it can be different what Firebird windows installer does, and what it is possible to configure afterwards.
What I think would be nice to have is a possibility to configure to store the firebird.log file in another place or to disable it.
For example like it is possible to change RootDirectory from firebird.conf file.
What are the problems to allow to do this?
In that case once could distribute embedded firebird with conf file which does the job.
With best regards
Fra: Paul Reeves [mailto:***@ibphoenix.com]
Sendt: 21. september 2010 11:59
Til: For discussion among Firebird Developers
Emne: Re: [Firebird-devel] Redirect or disable firebird.log file - Email found in subject
The reasons why the windows installer hasn't evolved to support the new windows deployment rules are quite simple.
o Firebird has inherently assumed everything is in a single directory.
o Historically we have always deployed to a single directory.
o The directory structure is identical across platforms.
(Dont know about the Mac). This is definitely a feature.
o Most O/S have work arounds to support deployment to a single directory
so we have been able to continue this practice.
o A lot of users like to just unzip a package without doing any
installation. They consider this a feature.
Until recently no real work had been done to unravel this to allow support for deployment according to O/S specific rules. This has now changed for linux and pretty much everything is configurable at build time, so it is possible to create packages that deploy correctly for a particular distribution. However this does require distribution specific packages.
AFAIU we are still not quite there for Windows, and I wonder if it is even going to be easy. The posix environment allows symlinks which makes it easy to deploy files all over the place while still presenting a single directory tree to the system admin.
What we need to do is to decide where we want to go with this.
How far do we want to travel in the direction of O/S conformance?
How important is it to keep things simple by keeping everything in one place?
How much of a support headache will it be (for example) if we have get users to hunt all over their system to find the firebird.log file?
If we are going to make changes we should start at the beginning of the development cycle with Firebird 3 alpha. If the changes make sense and users understand them then we could consider backporting some to (say) 2.5. But lets be sure we understand what we are doing first.
Specialists in Firebird support