Discussion:
[Firebird-devel] Redirect or disable firebird.log file - Email found in subject
Leyne, Sean
2010-09-20 16:32:10 UTC
Permalink
I think this is just another prove the need of possibility to redirect
the firebird.log. It is not fully supported and advisable for windows
applications to write to Program file folder.
In addition to it- our application must pass the Designed for Windows
tests. And it will never pass it if it is using a dll which is writing to Program
File folder.
So, don't install Firebird into "Program Files" if you have strong need to
pass these tests.
"Designed for Windows" requires that applications install into Program Files. Further, as of Vista, all configuration and log files must be located into %Application Data%\All Users\{Application} or %Application Data%\%Current User%\{Application} folders.

The Firebird install packages should be changed to meet the newer Windows requirements -- the changes are not that significant, but the current installs can cause significant issues for deployments.


Sean
Vlad Khorsun
2010-09-20 18:35:07 UTC
Permalink
Post by Leyne, Sean
I think this is just another prove the need of possibility to redirect
the firebird.log. It is not fully supported and advisable for windows
applications to write to Program file folder.
In addition to it- our application must pass the Designed for Windows
tests. And it will never pass it if it is using a dll which is writing to Program
File folder.
So, don't install Firebird into "Program Files" if you have strong need to
pass these tests.
"Designed for Windows" requires that applications install into Program Files.
Further, as of Vista, all configuration and log files must be located into
%Application Data%\All Users\{Application} or
%Application Data%\%Current User%\{Application} folders.
Seems You missed the point. Liana installs *own* application which is used
Firebird *Embedded*. Since v2.5 it is possible to put embedded into its own folder
different from application's one. As it is not possible to put firebird.log into folder
different from fbembed.dll i suggest to don't put whole Embedded package into
"Program Files" folder.
Post by Leyne, Sean
The Firebird install packages should be changed to meet the newer Windows
requirements -- the changes are not that significant, but the current installs
can cause significant issues for deployments.
Are we going to get "Designed for Windows" sign for Firebird ? :) Anyway,
it is not possible for all current Firebird versions to separate firebird.log from
fbembed.dll. Probably task for v3. If MS will not change rules again ;)

Regards,
Vlad
Adriano dos Santos Fernandes
2010-09-20 18:45:46 UTC
Permalink
Post by Vlad Khorsun
Seems You missed the point. Liana installs *own* application which is used
Firebird *Embedded*. Since v2.5 it is possible to put embedded into its own folder
different from application's one. As it is not possible to put firebird.log into folder
different from fbembed.dll i suggest to don't put whole Embedded package into
"Program Files" folder.
This does not mean her application will be ok accordingly to the MS
rules, will be?

Since from the test POV, fbembed is part of her application. It's like
wanting Linux distros to put binaries in /etc or /var...


Adriano
Vlad Khorsun
2010-09-20 19:15:41 UTC
Permalink
Post by Adriano dos Santos Fernandes
Post by Vlad Khorsun
Seems You missed the point. Liana installs *own* application which is used
Firebird *Embedded*. Since v2.5 it is possible to put embedded into its own folder
different from application's one. As it is not possible to put firebird.log into folder
different from fbembed.dll i suggest to don't put whole Embedded package into
"Program Files" folder.
This does not mean her application will be ok accordingly to the MS
rules, will be?
I don't know. This is best i can suggest for now. Do you have better idea ?

Regards,
Vlad
marius adrian popa
2010-09-21 09:27:13 UTC
Permalink
On Mon, Sep 20, 2010 at 9:45 PM, Adriano dos Santos Fernandes
Post by Adriano dos Santos Fernandes
     Seems You missed the point. Liana installs *own* application which is used
Firebird *Embedded*. Since v2.5 it is possible to put embedded into its own folder
different from application's one. As it is not possible to put firebird.log into folder
different from fbembed.dll i suggest to don't put whole Embedded package into
"Program Files" folder.
This does not mean her application will be ok accordingly to the MS
rules, will be?
Since from the test POV, fbembed is part of her application. It's like
wanting Linux distros to put binaries in /etc or /var...
I agree fbembedded should be self contained dll with no other config ,
log and other files like the sqlite does
ok ok only icu so/dll are needed
Post by Adriano dos Santos Fernandes
Adriano
------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Alex Peshkoff
2010-09-21 09:39:34 UTC
Permalink
Post by marius adrian popa
On Mon, Sep 20, 2010 at 9:45 PM, Adriano dos Santos Fernandes
Post by Adriano dos Santos Fernandes
Post by Vlad Khorsun
Seems You missed the point. Liana installs *own* application which is used
Firebird *Embedded*. Since v2.5 it is possible to put embedded into its own folder
different from application's one. As it is not possible to put firebird.log into folder
different from fbembed.dll i suggest to don't put whole Embedded package into
"Program Files" folder.
This does not mean her application will be ok accordingly to the MS
rules, will be?
Since from the test POV, fbembed is part of her application. It's like
wanting Linux distros to put binaries in /etc or /var...
I agree fbembedded should be self contained dll with no other config ,
log and other files
Very good suggestion - but please explain what to do if severe error
takes place in helper thread, where we have absolutely no way to deliver
it to user in regular status vector? Ignore? Abort application? Format HDD?
Alex Peshkoff
2010-09-21 07:35:13 UTC
Permalink
Post by Leyne, Sean
I think this is just another prove the need of possibility to redirect
the firebird.log. It is not fully supported and advisable for windows
applications to write to Program file folder.
In addition to it- our application must pass the Designed for Windows
tests. And it will never pass it if it is using a dll which is writing to Program
File folder.
So, don't install Firebird into "Program Files" if you have strong need to
pass these tests.
"Designed for Windows" requires that applications install into Program Files. Further, as of Vista, all configuration and log files must be located into %Application Data%\All Users\{Application} or %Application Data%\%Current User%\{Application} folders.
Better late than never! I mean that they at least decided to stop with
DOS-like practice of installing everything into single place.
Post by Leyne, Sean
The Firebird install packages should be changed to meet the newer Windows requirements -- the changes are not that significant, but the current installs can cause significant issues for deployments.
Afraid it's too late for 2.5, but in fb3 this should be definitely done.
Our codebase is completely ready to work without single FbRoot, the only
thing we need is to add windows specific tricks like taking into an
account %Application Data% variable.
Nando Dessena
2010-09-21 08:36:04 UTC
Permalink
Alex,
Post by Alex Peshkoff
Post by Leyne, Sean
So, don't install Firebird into "Program Files" if you have
strong need to pass these tests.
"Designed for Windows" requires that applications install into
Program Files. Further, as of Vista, all configuration and log
files must be located into %Application Data%\All
Users\{Application} or %Application Data%\%Current
User%\{Application} folders.
Better late than never! I mean that they at least decided to stop
with DOS-like practice of installing everything into single place.
I think that Windows guidelines have been stating this at least for the
last 6 years now. Better late than never that people actually read them. :-D
Post by Alex Peshkoff
Afraid it's too late for 2.5, but in fb3 this should be definitely
done. Our codebase is completely ready to work without single FbRoot,
the only thing we need is to add windows specific tricks like taking
into an account %Application Data% variable.
The installation program should probably also ask whether to install
"for the current user" or "for all users".
--
Nando Dessena
Liana Svendsen
2010-09-21 08:44:41 UTC
Permalink
Post by Alex Peshkoff
Afraid it's too late for 2.5, but in fb3 this should be definitely
done. Our codebase is completely ready to work without single FbRoot,
the only thing we need is to add windows specific tricks like taking
into an account %Application Data% variable.
The installation program should probably also ask whether to install
"for the current user" or "for all users".
--
I totally agree, but remember that in case of embedded use of firebird- it is the setup program of 'master' application which will ask where to install the program. And most logical is that the dlls go to chosen "Program files" folder and the data which the application is producing to Application Data or another folder which has write permissions.
Best regards
Liana
Nando Dessena
2010-09-21 09:04:16 UTC
Permalink
Liana,
Post by Liana Svendsen
Post by Nando Dessena
The installation program should probably also ask whether to
install "for the current user" or "for all users".
I totally agree, but remember that in case of embedded use of
firebird- it is the setup program of 'master' application which will
ask where to install the program. And most logical is that the dlls
go to chosen "Program files" folder and the data which the
application is producing to Application Data or another folder which
has write permissions.
Yes - and that application or setup program has to decide whether to use
%APPDATA% or %ALLUSERSPROFILE% I think.
--
Nando Dessena
Alex Peshkoff
2010-09-21 09:11:32 UTC
Permalink
Post by Nando Dessena
Alex,
Post by Alex Peshkoff
Post by Leyne, Sean
So, don't install Firebird into "Program Files" if you have
strong need to pass these tests.
"Designed for Windows" requires that applications install into
Program Files. Further, as of Vista, all configuration and log
files must be located into %Application Data%\All
Users\{Application} or %Application Data%\%Current
User%\{Application} folders.
Better late than never! I mean that they at least decided to stop
with DOS-like practice of installing everything into single place.
I think that Windows guidelines have been stating this at least for the
last 6 years now. Better late than never that people actually read them. :-D
Please take into an account that a lot of other operating systems had
such a requirement during at least 25 years - can't say for sure about
earlier times, but suppose this digit can be up to 40 years.
Post by Nando Dessena
Post by Alex Peshkoff
Afraid it's too late for 2.5, but in fb3 this should be definitely
done. Our codebase is completely ready to work without single FbRoot,
the only thing we need is to add windows specific tricks like taking
into an account %Application Data% variable.
The installation program should probably also ask whether to install
"for the current user" or "for all users".
This is very interesting point. If we talk about server install, IMO
such things should go to runuser's application data. When we talk about
client-only things - appears separate logs per client is correct. I.e.
always send log to current user's area.
Paul Reeves
2010-09-21 09:49:57 UTC
Permalink
Post by Nando Dessena
The installation program should probably also ask whether to install
"for the current user" or "for all users".
In order to deploy for a user we need to track which existing installs
use which tcp port, local protocol name and pipe name. We don't do this
and may never do this. So, for the time being at least the installer is
installing for all users. There is no point in asking the question.


Paul
--
Paul Reeves
http://www.ibphoenix.com
Specialists in Firebird support
Nando Dessena
2010-09-21 09:57:48 UTC
Permalink
Paul,
Post by Paul Reeves
Post by Nando Dessena
The installation program should probably also ask whether to
install "for the current user" or "for all users".
In order to deploy for a user we need to track which existing
installs use which tcp port, local protocol name and pipe name. We
don't do this and may never do this. So, for the time being at least
the installer is installing for all users. There is no point in
asking the question.
Of course there's no point currently.
I was talking about the eventuality, described in this thread, in which
support files are written in a data folder, in which case you should
decide whether it's the current user's data folder or the global one.
Many setup programs just ask.
--
Nando Dessena
Dimitry Sibiryakov
2010-09-21 10:01:22 UTC
Permalink
Post by Nando Dessena
I was talking about the eventuality, described in this thread, in which
support files are written in a data folder, in which case you should
decide whether it's the current user's data folder or the global one.
Firebird server has no user-specific support files, it used to run under system account.
--
SY, SD.
Alex Peshkoff
2010-09-21 13:11:09 UTC
Permalink
Post by Dimitry Sibiryakov
Post by Nando Dessena
I was talking about the eventuality, described in this thread, in which
support files are written in a data folder, in which case you should
decide whether it's the current user's data folder or the global one.
Firebird server has no user-specific support files, it used to run under system account.
What?
Does it still run an LocalSystem by default?
Paul Reeves
2010-09-21 09:59:05 UTC
Permalink
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.


Paul
--
Paul Reeves
http://www.ibphoenix.com
Specialists in Firebird support
Liana Svendsen
2010-09-21 12:41:10 UTC
Permalink
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
Liana
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.

Paul

--

Paul Reeves

http://www.ibphoenix.com

Specialists in Firebird support
Adriano dos Santos Fernandes
2010-09-21 12:49:08 UTC
Permalink
Post by Liana Svendsen
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.
What's the problem with suggested solution of making firebird.log
readonly or just let it there in unwritable place with others have said?


Adriano
Liana Svendsen
2010-09-21 12:55:10 UTC
Permalink
Post by Adriano dos Santos Fernandes
What's the problem with suggested solution of making firebird.log
readonly or just let it there in unwritable place with others have said?
Adriano
Because it doesn't look too professional for me to do it in that way. It looks more like a work around then a solution.
There is no firebird.log file to begin with. So As far as I understand, what is suggested is to create an empty read only firebird.log file and distribute it with application?
I am not sure that's a good solution.
What I do want to have firebird.log file but in Application data folder?
Best regards
Liana
Adriano dos Santos Fernandes
2010-09-21 13:05:14 UTC
Permalink
Post by Liana Svendsen
Because it doesn't look too professional for me to do it in that way. It looks more like a work around then a solution.
There is no firebird.log file to begin with. So As far as I understand, what is suggested is to create an empty read only firebird.log file and distribute it with application?
I am not sure that's a good solution.
AFAIU, your application need to *work* in the read only appfiles
directory. It doesn't mean Firebird shouldn't try to write to it. So if
firebird.log doesn't exist, it will work. You're asking for no
firebird.log, so...

You can also try to create a Windows symbolic link referencing the
appdata directory.


Adriano
Alex Peshkoff
2010-09-21 13:13:16 UTC
Permalink
Post by Adriano dos Santos Fernandes
Post by Liana Svendsen
Because it doesn't look too professional for me to do it in that way. It looks more like a work around then a solution.
There is no firebird.log file to begin with. So As far as I understand, what is suggested is to create an empty read only firebird.log file and distribute it with application?
I am not sure that's a good solution.
AFAIU, your application need to *work* in the read only appfiles
directory. It doesn't mean Firebird shouldn't try to write to it. So if
firebird.log doesn't exist, it will work. You're asking for no
firebird.log, so...
You can also try to create a Windows symbolic link referencing the
appdata directory.
This is good hack to make 2.X to do what Liana needs, but not correct
long term solution.
Geoff Worboys
2010-09-21 13:21:18 UTC
Permalink
Post by Adriano dos Santos Fernandes
What's the problem with suggested solution of making
firebird.log readonly or just let it there in unwritable
place with others have said?
Yuck! I agree with Liana, that smacks of a temporary work-
around rather than a real solution.

It is way past time that Firebird looked at properly
integrating into the operating system. On Windows that
means writing to the system application event log, on *nix
systems I imagine that means writing to the var/log
directory.

I don't have experience managing Linux systems so can't say
what Firebird is like there but I do know that lack of
integration under Windows is a definite mark-down for people
evaluating Firebird. Administrators have various automated
tools that they use for monitoring the Windows systems logs,
the fact that Firebird does not write there means that
separate procedures must be instituted to monitor it (but
more often than not it is simply ignored).

Not that this is anything new:
http://tracker.firebirdsql.org/browse/CORE-791

If you are going to change log processing then I suggest you
look at doing it properly.

A "good" solution (IMO) would work something like this:

1. default/installed instances would write to operating
system appropriate log location (var/log on *nix,
system event logs on Windows, ? on mac).

2. zip/portable instances would write to the bin
directory unless directed elsewhere

3. firebird.conf options used to override defaults.


Even the location of firebird.conf is interesting but that's
another story I guess.
--
Geoff Worboys
Telesis Computing
Adriano dos Santos Fernandes
2010-09-21 16:43:04 UTC
Permalink
Post by Geoff Worboys
Post by Adriano dos Santos Fernandes
What's the problem with suggested solution of making
firebird.log readonly or just let it there in unwritable
place with others have said?
Yuck! I agree with Liana, that smacks of a temporary work-
around rather than a real solution.
And generally people need workarounds, because they can't wait years to
see they wishes implemented in the next major version.
Post by Geoff Worboys
It is way past time that Firebird looked at properly
integrating into the operating system. On Windows that
means writing to the system application event log, on *nix
systems I imagine that means writing to the var/log
directory.
And Linux distro people contributes and helps with code to implement
they wishes.

I do not understand why the Windows people always wait for the core team
to implement things every Windows developer understand.


Adriano
Vlad Khorsun
2010-09-21 18:22:31 UTC
Permalink
Post by Adriano dos Santos Fernandes
Post by Geoff Worboys
Post by Adriano dos Santos Fernandes
What's the problem with suggested solution of making
firebird.log readonly or just let it there in unwritable
place with others have said?
Yuck! I agree with Liana, that smacks of a temporary work-
around rather than a real solution.
And generally people need workarounds, because they can't wait years to
see they wishes implemented in the next major version.
Exactly
Post by Adriano dos Santos Fernandes
Post by Geoff Worboys
It is way past time that Firebird looked at properly
integrating into the operating system. On Windows that
means writing to the system application event log, on *nix
systems I imagine that means writing to the var/log
directory.
And Linux distro people contributes and helps with code to implement
they wishes.
I do not understand why the Windows people always wait for the core team
to implement things every Windows developer understand.
Completely agree.

Regards,
Vlad
Geoff Worboys
2010-09-22 00:07:25 UTC
Permalink
Post by Adriano dos Santos Fernandes
I do not understand why the Windows people always wait for
the core team to implement things every Windows developer
understand.
Well I suppose it depends on how you see the project.

Is it like zlib and other developer libraries, where the
end developer is responsible for all elements of the
installation.

Or is it a server application that should be able to be
installed more generally and used by whatever application
happens to need it.

It seems to me that most here and on support treat Firebird
like the latter - in which case the main build is expected to
have certain features and my previous post was an expression
of what I thought was appropriate. I don't really care who
does the actual writing.

But, to be honest, I treat it like the former, so yes I deal
with the installation issues myself. For my own requirements
I am happy for Firebird to ignore installation and operating
system issues because I will continue to implement my own.
--
Geoff Worboys
Telesis Computing
Liana Svendsen
2010-09-22 05:49:27 UTC
Permalink
Post by Geoff Worboys
http://tracker.firebirdsql.org/browse/CORE-791
By the way there is also an unassigned issue about firebird.log in firebird tracker, posted 24.07.2009

http://tracker.firebirdsql.org/browse/CORE-2571

Liana Svendsen
Maestro soft, Norway.
Cosmin Apreutesei
2010-09-21 12:37:36 UTC
Permalink
Most popular servers today have runtime config options for setting up
filesystem layout (path of pid file, log file, etc.), and a
command-line option on the server executable for the path of the
config file itself, making them completely portable. Best ones even
allow all the paths to be given on command-line (BSD stuff like ntpd,
pure-ftpd come to mind), making it trivial to wrap a startup script
that configures the server using env. vars, etc. They also feature
logging to the system logger, so no HDD formatting needed if error.log
is disabled, thank you.

This would simplify devs life too, leaving the distros the freedom and
responsibility of making Firebird fit into their own layout (guess why
everybody else is doing it). Windows conformance would be trivialized
to changing a few lines in fbserver.bat every once in a while. The
feature of having everything into one directory would be preserved
with just defaults on these config options.
Alex Peshkoff
2010-09-21 13:15:48 UTC
Permalink
Post by Cosmin Apreutesei
Most popular servers today have runtime config options for setting up
filesystem layout (path of pid file, log file, etc.), and a
command-line option on the server executable for the path of the
config file itself, making them completely portable. Best ones even
allow all the paths to be given on command-line (BSD stuff like ntpd,
pure-ftpd come to mind), making it trivial to wrap a startup script
that configures the server using env. vars, etc. They also feature
logging to the system logger, so no HDD formatting needed if error.log
is disabled, thank you.
This would simplify devs life too, leaving the distros the freedom and
responsibility of making Firebird fit into their own layout (guess why
everybody else is doing it). Windows conformance would be trivialized
to changing a few lines in fbserver.bat every once in a while. The
feature of having everything into one directory would be preserved
with just defaults on these config options.
Cosmin, where is dll's (I mean first of fbembed.dll) command line? :)
Cosmin Apreutesei
2010-09-21 13:21:08 UTC
Permalink
Tough one :) How 'bout an API call ?
Post by Alex Peshkoff
Post by Cosmin Apreutesei
Most popular servers today have runtime config options for setting up
filesystem layout (path of pid file, log file, etc.), and a
command-line option on the server executable for the path of the
config file itself, making them completely portable. Best ones even
allow all the paths to be given on command-line (BSD stuff like ntpd,
pure-ftpd come to mind), making it trivial to wrap a startup script
that configures the server using env. vars, etc. They also feature
logging to the system logger, so no HDD formatting needed if error.log
is disabled, thank you.
This would simplify devs life too, leaving the distros the freedom and
responsibility of making Firebird fit into their own layout (guess why
everybody else is doing it). Windows conformance would be trivialized
to changing a few lines in fbserver.bat every once in a while. The
feature of having everything into one directory would be preserved
with just defaults on these config options.
Cosmin, where is dll's (I mean first of fbembed.dll) command line? :)
------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Alex Peshkoff
2010-09-21 14:05:40 UTC
Permalink
Post by Cosmin Apreutesei
Tough one :) How 'bout an API call ?
That's possible.
But unlike command line for server not much better than environment or
conf file...
Alex Peshkoff
2010-09-21 13:08:21 UTC
Permalink
Post by Paul Reeves
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.
Though this is offtopic in this thread, I want to raise a related
question. A lot (better say most of) projects do not provide linux
binary packages at all. This is left for distros (or people can build
from sources themselves). Both options were problematic at the first
days of firebird. Now we have both easy-to-build src tarball and good
support in various distros. May be it's time to stop with binaries since
3.0?
Post by Paul Reeves
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.
Windows provides symlinks too starting with Vista(?), but they are not
needed. In linux distro packages files are physically (and it's
sometimes important!) placed according to OS rules.
Post by Paul Reeves
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?
Telling true I think that OS conformance is good thing. If we continue
ignoring it, we may soon meet a case when firebird.log simply can't be
written to 'Program Files' at all.
Post by Paul Reeves
How important is it to keep things simple by keeping everything in one place?
I'm not 100% sure that this IS a way to keep things simple:) Getting
serious - this is nothing more than traditional for us.
Post by Paul Reeves
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?
Less compared with a case when it's not written at all. Once again - the
most correct way is to at least duplicate it in system log.
Post by Paul Reeves
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.
Paul, I do not think that this changes are so critical and massive to
require them at early stages. At least for posix I've made them far from
early alpha stages, closer to late betas. Next, almost all required in
codebase changes are already in it. What we need is minimum tuning for
windows.

And what do you think about old firebird rules for .zip but new windows
rules for .exe?
Adriano dos Santos Fernandes
2010-09-21 13:20:06 UTC
Permalink
Post by Alex Peshkoff
Post by Paul Reeves
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.
Though this is offtopic in this thread, I want to raise a related
question. A lot (better say most of) projects do not provide linux
binary packages at all. This is left for distros (or people can build
from sources themselves). Both options were problematic at the first
days of firebird. Now we have both easy-to-build src tarball and good
support in various distros. May be it's time to stop with binaries since
3.0?
I think that don't make much sense. Today Linux are much more used by
not-very tech people.

Some of those (students, for example) may want to work with latest (many
times not present in his distro) version and may not be able to compile it.

We should make their life easier...


Adriano
Alex Peshkoff
2010-09-21 13:45:00 UTC
Permalink
Post by Adriano dos Santos Fernandes
Post by Alex Peshkoff
Post by Paul Reeves
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.
Though this is offtopic in this thread, I want to raise a related
question. A lot (better say most of) projects do not provide linux
binary packages at all. This is left for distros (or people can build
from sources themselves). Both options were problematic at the first
days of firebird. Now we have both easy-to-build src tarball and good
support in various distros. May be it's time to stop with binaries since
3.0?
I think that don't make much sense. Today Linux are much more used by
not-very tech people.
Some of those (students, for example) may want to work with latest (many
times not present in his distro) version and may not be able to compile it.
We should make their life easier...
May be with gentoo I've forgotten that a lot of gcc-less installations
exist today. Probably you are right.
Philippe Makowski
2010-09-21 13:46:47 UTC
Permalink
Post by Adriano dos Santos Fernandes
Post by Alex Peshkoff
Post by Paul Reeves
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.
Though this is offtopic in this thread, I want to raise a related
question. A lot (better say most of) projects do not provide linux
binary packages at all. This is left for distros (or people can build
from sources themselves). Both options were problematic at the first
days of firebird. Now we have both easy-to-build src tarball and good
support in various distros. May be it's time to stop with binaries since
3.0?
I think that don't make much sense. Today Linux are much more used by
not-very tech people.
Some of those (students, for example) may want to work with latest (many
times not present in his distro) version and may not be able to compile it.
We should make their life easier...
I tend to agree with Alex, since building Firebird is very easy

There is a medium position I thing we should stop provide rpm (that are not good rpm
because they don't manage well dependencies and not allow upgrade)
tar.gz build only are ok.
having official build is also a good thing for Q/A and bug check, to be sure that the bug
is not related to a bad distro patch that can append.

and pg for example provide (with the help of enterprisedb) binaries installers

maybe we could ask for a license for BitRock Installer
http://installbuilder.bitrock.com/open-source-licenses.html
Alex Peshkoff
2010-09-21 14:11:06 UTC
Permalink
Post by Philippe Makowski
Post by Adriano dos Santos Fernandes
Post by Alex Peshkoff
Post by Paul Reeves
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.
Though this is offtopic in this thread, I want to raise a related
question. A lot (better say most of) projects do not provide linux
binary packages at all. This is left for distros (or people can build
from sources themselves). Both options were problematic at the first
days of firebird. Now we have both easy-to-build src tarball and good
support in various distros. May be it's time to stop with binaries since
3.0?
I think that don't make much sense. Today Linux are much more used by
not-very tech people.
Some of those (students, for example) may want to work with latest (many
times not present in his distro) version and may not be able to compile it.
We should make their life easier...
I tend to agree with Alex, since building Firebird is very easy
There is a medium position I thing we should stop provide rpm (that are not good rpm
because they don't manage well dependencies and not allow upgrade)
yes, our rpm's are very bad
primarily because they try to support all distro in one rpm
Post by Philippe Makowski
tar.gz build only are ok.
having official build is also a good thing for Q/A and bug check, to be sure that the bug
is not related to a bad distro patch that can append.
And when we ask user to send us core file...
Post by Philippe Makowski
and pg for example provide (with the help of enterprisedb) binaries installers
maybe we could ask for a license for BitRock Installer
http://installbuilder.bitrock.com/open-source-licenses.html
Do not think that GUI installer is required for database server, but see
no problems is someone does it.
Philippe Makowski
2010-09-21 14:33:10 UTC
Permalink
Post by Alex Peshkoff
Post by Philippe Makowski
There is a medium position I thing we should stop provide rpm (that are not good rpm
because they don't manage well dependencies and not allow upgrade)
yes, our rpm's are very bad
primarily because they try to support all distro in one rpm
I know that ;)
it's not your fault
Post by Alex Peshkoff
Post by Philippe Makowski
tar.gz build only are ok.
having official build is also a good thing for Q/A and bug check, to be sure that the bug
is not related to a bad distro patch that can append.
And when we ask user to send us core file...
+1
Post by Alex Peshkoff
Post by Philippe Makowski
and pg for example provide (with the help of enterprisedb) binaries installers
maybe we could ask for a license for BitRock Installer
http://installbuilder.bitrock.com/open-source-licenses.html
Do not think that GUI installer is required for database server, but see
no problems is someone does it.
it was just to answer to
Post by Alex Peshkoff
Post by Philippe Makowski
Post by Adriano dos Santos Fernandes
We should make their life easier...
and if we can have a unified installer for Windows, Linux and MacOsx, why not try

Paul R did you look at BitRock solution one day ?
Paul Reeves
2010-09-21 15:04:59 UTC
Permalink
Post by Philippe Makowski
Paul R did you look at BitRock solution one day ?
It seems to be a closed source solution.

But what advantages would BitRock bring?


Paul
--
Paul Reeves
http://www.ibphoenix.com
Specialists in Firebird support
Dmitry Yemanov
2010-09-21 15:40:15 UTC
Permalink
Post by Paul Reeves
It seems to be a closed source solution.
So what? MSVC is closed source as well.
Post by Paul Reeves
But what advantages would BitRock bring?
AFAIU, it would allow us to have a single installer unified across the
major supported platforms. If it worked for MySQL, supposedly it could
work for us too.


Dmitry
marius adrian popa
2010-09-21 15:54:53 UTC
Permalink
Post by Alex Peshkoff
Post by Philippe Makowski
Post by Adriano dos Santos Fernandes
Post by Alex Peshkoff
  >
Post by Paul Reeves
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.
Though this is offtopic in this thread, I want to raise a related
question. A lot (better say most of) projects do not provide linux
binary packages at all. This is left for distros (or people can build
from sources themselves). Both options were problematic at the first
days of firebird. Now we have both easy-to-build src tarball and good
support in various distros. May be it's time to stop with binaries since
3.0?
I think that don't make much sense. Today Linux are much more used by
not-very tech people.
Some of those (students, for example) may want to work with latest (many
times not present in his distro) version and may not be able to compile it.
We should make their life easier...
I tend to agree with Alex, since building Firebird is very easy
There is a medium position I thing we should stop provide rpm (that are not good rpm
because they don't manage well dependencies and not allow upgrade)
yes, our rpm's are very bad
primarily because they try to support all distro in one rpm
Post by Philippe Makowski
tar.gz build only are ok.
having official build is also a good thing for Q/A and bug check, to be sure that the bug
is not related to a bad distro patch that can append.
And when we ask user to send us core file...
Post by Philippe Makowski
and pg for example provide (with the help of enterprisedb) binaries installers
maybe we could ask for a license for BitRock Installer
http://installbuilder.bitrock.com/open-source-licenses.html
Do not think that GUI installer is required for database server, but see
no problems is someone does it.
let's upgrade the stdc++ requirements version first Doru Ilasi for
example he really tried to install firebird 2.5 on his Ubuntu lts
machine but failed
because there is no such old stdc++ only in debian but is hard to
install and find

so he had to just compile it from source

ps: on debian , ubuntu .deb is the norm and i think google chrome use
it and i really like this aproach
also people don't complain on installing the actual installer seems to
be fine , or they really use the debian way
apt-get install firebird2.5-superclassic and that is all

I don't really want an Oracle style wizzard :) with java requirement ,
maybe for a set of firebird tools would be a good idea a gui type
installer like in nokia qt sdk
Post by Alex Peshkoff
------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Nando Dessena
2010-09-21 14:45:44 UTC
Permalink
Alex,
Post by Alex Peshkoff
Windows provides symlinks too starting with Vista(?)
I am almost sure I have been using hardlinks and junctions on NTFS since
Win2k. But apparently nobody uses them.
--
Nando Dessena
Paul Beach
2010-09-21 16:19:46 UTC
Permalink
Post by Paul Reeves
It seems to be a closed source solution.
So what? MSVC is closed source as well.
Post by Paul Reeves
But what advantages would BitRock bring?
<<AFAIU, it would allow us to have a single installer unified across the
major supported platforms. If it worked for MySQL, supposedly it could
work for us too.>>

My 2c - where possible I think we should be using the native installers provided by
the O/S vendor. OK - we have to support multiple installers... but I consider it
to be a cleaner solution.

Paul
Alex Peshkoff
2010-09-22 06:18:45 UTC
Permalink
Post by Paul Beach
My 2c - where possible I think we should be using the native installers provided by
the O/S vendor. OK - we have to support multiple installers... but I consider it
to be a cleaner solution.
And I have to add - when possible. Currently (2.5) we have ports (i.e.
compilation succeeds) for almost all unix platforms, but installers are
not fixed for a lot of them. I.e. having one common installer is
definitely better than no installer for any OS.

Leyne, Sean
2010-09-21 21:01:26 UTC
Permalink
Vlad/Adriano,
Post by Adriano dos Santos Fernandes
I do not understand why the Windows people always wait for the core
team to implement things every Windows developer understand.
Unless someone is fluent in the Innosetup script language, it is very difficult to submit changes/improvements.


Sean
Vlad Khorsun
2010-09-21 21:22:48 UTC
Permalink
Post by Leyne, Sean
Vlad/Adriano,
Post by Adriano dos Santos Fernandes
I do not understand why the Windows people always wait for the core
team to implement things every Windows developer understand.
Unless someone is fluent in the Innosetup script language, it is very difficult to submit changes/improvements.
Did you ever tried to look at it ? It is far far very far from "rocket science"...

Regards,
Vlad

PS Feel free to create MSI packages
Loading...