[pkg-firebird-general] Server packages for Firebird 2.5

[marius popa]

On Mon, Oct 20, 2008 at 10:52 AM, marius popa <mapopa at gmail.com> wrote:
> On Mon, Oct 20, 2008 at 10:23 AM, Damyan Ivanov <dmn at debian.org> wrote:
>> Last weekend I started work on packaging Firebird 2.5 (alpha1).
>>
>> Firebird 2.5 has the new "SuperClassic" flavour that should be fine
>> with all use cases - SMP or not. I think it also has a page cache that
>> is shared across connections so it looks definitely better than both
>> -super and -classic in all regards[1]. I wonder if there is any reason
>> to provide the -super and -classic packages in their current meaning.
>>
>>    [1] except if there is a bug in one connection, it could bring the
>>    whole server down. I think that this is not a very big problem. If
>>    there is a bug that can take down one connection, it should be
>>    fixed anyway as it can bring down any (thus all) connections.
>>
>> Providing only firebird2.5-server (containing the SuperClassic
>> flavour) would simplify the packaging, not to mention it would cut the
>> package build time in half (now both -super and -classic are built).
>>
>> Abandoning multiple -server packages would also elliminate the
>> -server-common package. The final list of packages would be
>>
>>  firebird2.5-server
>>  libfbclient2
>>  libfbembed2.5
>>  firebird2.5-common
>>  firebird2.5-dev
>>  firebird2.5-examples
>>  firebird2.5-doc
>>
>> What do you think? If SuperClassic is here, would anyone miss the
>> -super and -classic flavours?
> I think we should have
> Super with normal usage and super classic flavor
> firebird-super will contain the super-classic too ?
> From what i uderstand is an switch to the super (Maybe i'm wrong i will check)
>
well i'm wrong is an single switch to the windows version on posix
there is an new binary

On POSIX, the new binary fb_smp_server is supplied for the
Superclassic model. It contains the network listener, meaning it works
similarly to fbserver with regard to attachment requests and does not
require [x]inetd.

The multi-threaded engine used by fb_smp_server is the libfbembed.so
library, in accordance with OSRI requirements. The Classic packages
also include fbguard (the Guardian) which, for Classic, starts
fb_smp_server, rather than fbserver as it does when the Superserver
model is installed with Guardian.

http://firebirdsql.org/devel/doc/rlsnotes/html/rlsnotes25.html#rnfb25-engine-threading

> with old classic it should stay the same because I talked with Dimitry
> Yemanov and he said that
> you can still use the old classic in situations where you need to be safe
> for example :in case one connection crashes then it tears down all the
> super and super-classic but not the
> old classic and all the other connections are not affected by this in
> the old classic mode
> So if you don't care if old classic eats a lot of memory and resources
> (big server with 32 core 512G of ram for example)
> then stay with classic .
>
> ps: i will try to setup distcc to build firebird maybe it will be faster :)
>
>>
>> --
>> dam            JabberID: dam at jabber.minus273.org
>>
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.9 (GNU/Linux)
>>
>> iEYEARECAAYFAkj8MdsACgkQHqjlqpcl9jue1wCfRVKNrRJkIuRpY5EhoA8T0fFQ
>> 6kwAnjj4d1JibXWJKMB+fgCiAv33vgTc
>> =k9Qw
>> -----END PGP SIGNATURE-----
>>
>> _______________________________________________
>> pkg-firebird-general mailing list
>> pkg-firebird-general at lists.alioth.debian.org
>> http://lists.alioth.debian.org/mailman/listinfo/pkg-firebird-general
>>
>
>
>
> --
> developer flamerobin.org
>



-- 
developer flamerobin.org