[pkg-firebird-general] Re: Being a beta tester for Firebird 2package on Debian

[Valdir Marcos]

Hi Damyan.

I agree with you about the coexistence.

Could you chance the names "firebird2-super-server" and 
"firebrid2-2.0-super-server" to "firebird15-super-server" and 
"firebrid20-super-server" because very soon we are going to have FB 2.1, 
2.5, 3.0 and 3.1 according to international news (Dmitry Yemanov in Prague 
November 2006)?

Again, could the directories be "/etc/firebird15" and "/etc/firebird20"?

Could this instalations create the users and groups "firebird15" and 
"firebird20"?

> This is why I'd prefer to have both versions installable, even if not at 
> the same time.

If we change all those information of my questions we can make many firebird 
server versions coexist without problems.

I have no experience on subversion software or building deb files, but I 
learn very fast. Can you teach me the first steps so I can help you with 
firebird and flamerobin deb files?

If we can create firebird and flamerobin deb files, many users can install 
them by dpkg while these deb files are not accepted as "stable" by Debian 
administrators! As a matter of fact, nowadays, I install them on Debian by 
"tar.gz" file...

Sincerely,

Valdir


----- Original Message ----- 
From: "Damyan Ivanov" <dam at modsoftsys.com>
To: "Valdir Marcos" <valdir.marcos at ig.com.br>
Cc: "Debian Firebird Packages" 
<pkg-firebird-general at lists.alioth.debian.org>; "Pierre YAGER" 
<pierre at crisalid.com>; <zedalaye at neuf.fr>
Sent: Thursday, November 23, 2006 7:01 PM
Subject: Re: [pkg-firebird-general] Re: Being a beta tester for Firebird 
2package on Debian


> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Valdir Marcos написа:
>> The standard installation of any Debian program (via apt-get) is to
>> overwrite its pevious versions.
>
> I plan for different set of packages that conflicts with 1.5 packages,
> so only one is installed at a moment, but the possibility to use 1.5 and
> 2.0 remains, with the constraint that you can't use them simultaneously.
> Read below.
>
>> The standard installation of FB 2.0 overwrite FB 1.5, but making both
>> coexist is not difficult.
>
> No two processes can listen on port 3050 at the same time. And no two
> pakcages can provide the same binary (/usr/bin/gfix for example) and be
> installed simultaneously. I prefer to keep the default port (and default
> utilities' names), since otherwise a major incompatibility with upstream
> is created.
>
>> We could make this could make this coexistence by two ways:
>
> I intent to go this way:
>
> Two sets of packages are created. Currently we have (this is version
> 1.5, despite the "2" in package names):
> libfbclient1
> libfbembed1
> firebrid2-super-server
> firebird2-classic-server
> firebird2-server-common
> firebird2-utils-super
> firebird2-utils-classic
> firebird2-common
> firebird2-dev
> firebird2-examples
>
> I plan that 2.0 version of firebird creates:
> libfbclient2
> libfbembed2
> firebrid2-2.0-super-server (conflicts with firebird2-super-server)
> firebird2-2.0-classic-server (conflicts with firebird2-classic-server)
> firebird2-2.0-server-common
> firebird2-2.0-utils-super (conflicts with firebird2-utils-*)
> firebird2-2.0-utils-classic (conflicts with firebird2-utils-*)
> firebird2-2.0-common
> firebird2-dev
> firebird2-2.0-examples
>
> The idea is that you may have only one server and one -utils- package
> installed, but may go back and forth between 1.5 and 2.0 versions.
>
> library and other packages have no restrictions, since they either
> contain files with fifferent names (libfb*) or use different directories
> (-common, -examples).
>
> Another major difference between 1.5 and 2.0 server packages is that
> they use different directories for storing databases and configuration.
>
> 1.5
> DB: /var/lib/firebird2/data
> conf: /etc/firebird2
>
> 2.0
> DB: /var/lib/firebird2/2.0/data
> conf: /etc/firebird2/2.0
>
> This way makes possible to back up all databases with 1.5, install 2.0
> (removing 1.5), restore, test. If something goes wrong, 1.5 may be
> installed back (removing 2.0), databases corrected, backed up, then 2.0
> installed (removing 1.5), restored and etc ad infinitum :)
>
> firebird2-dev is special, the 2.0-version of that package will become
> the "authoritative" -dev package, making other packages built with it to
> ise libfbclient2 instead of libfbclient1 (resp. libfbembed). This is the
> way to make packages that depend on firebird library to start using 2.0
> client library. At this point the 1.5 source package will stop producing
> firebird2-dev package.
>
>> 1. Changing the installation/uninstallation scripts of both versions on
>> variables such as:
>> - FBRootDir=/opt/firebird
>
> Hey, this is Debian. /opt is not an option :)
>
>> The question that remains is "should we change Debian and Firebird
>> natural installation behavior?".
>
> It is my belief that the answer is "no". I believe we can have the best
> from both worlds.
>
>> I know that depending on how somebody builds its sql statements this
>> migration from 1.5 to 2.0 maybe very traumatic.
>
> This is why I'd prefer to have both versions installable, even if not at
> the same time.
>
>> I also know that some people still need to mix Interbase (5.x, 6.x, 7.x)
>> and Firebird (1.x, 2.x) because of many reasons, such as different
>> vendors, old applications, etc, but how can we inform in the apt-get
>> that FB 2.0 installation will overwrite FB 1.5 or not?
>
> I guess I've explained that above. I'd like to add that people
> installing Interbase or non-debian Firebirds on Debian box should know
> how to do it without interfering with the package management system.
> /opt and /local are exactly for this.
>
>> If is there anything that I can help, I want to contribute.
>
> Good :) Do you have experience in debian package internals? If yes,
> please take a look at the SVN repository used for debian packages. It is
> at http://svn.debian.org/wsvn/pkg-firebird
>
> 1.5 is in branches/stable and branches/sid-1.5
> 2.0 is in branches/2.0.0
>
> your advice on packaging techniques would be very welcome.
>
> If you don't happen to have that knowledge, it's all right. Please line
> on the queue of beta-testers, along with Pierre :) I hope to be able to
> prepare 2.0 packages this weekend. Testing is even more important than
> development, since users happen to have so different requirements and
> approaches that no developer can foresee everything.
>
>
> this mail got too long, sorry. Now off to bed so I can get up tomorrow :)
>
>
> Regards,
> dam
> - --
> Damyan Ivanov                           Modular Software Systems
> dam at modsoftsys.com
> phone +359(2)928-2611, 929-3993              fax +359(2)920-0994
> mobile +359(88)856-6067             dam at jabber.minus273.org/Gaim
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.5 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFFZgwnHqjlqpcl9jsRAu6cAKC6oFlx4gIjsh8BP0QEa8m4apyFiACgkbHp
> Jl8MzJWAdo0oolgShpY0AeA=
> =zZok
> -----END PGP SIGNATURE-----
>
>