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

[Valdir Marcos]

Hi Dam.

> I can try to rename firebird2 to firebird-1.5 and firebird2-2.0 to
> firebird-2.0, yes. Renaming packages with complicated
> inter-dependencies is not my favourite, but I agree this is the way to go.

Very good.

> I'd prefer /etc/firebird/1.5/  /etc/firebird/2.0 etc

It much better than mu idea! Perfect!


> > Could this instalations create the users and groups "firebird15" and
> > "firebird20"?
>
> Why separate users/groups for each version? What's wrong with single
> user? All apache versions use the same user - www-data.
>

My experience: I installed both 1.5 and 2.0 manually on a client. I used 
them for a week, them uinstalled 1.5 (bu script) which "deleted" the user 
and group for both 1.5 and 2.0...
If the user is the same for all versions, its even better, but we have to 
care of not deleting it when uninstalling and there is still another version 
remaining.

> Some binaries are in /usr/bin and I don't want to have
> /usr/bin/gfix-1.5 and /usr/bin/gfix-2.0 - it's ugly and an overkill
> having in mind that the typical installation will have only one
> version installed.

I agree with about ugliness, but gfix and gbak are a little different in 1.5 
and 2.0 as you can see in http://www.destructor.de/firebird/gfix.htm 
(Extended State Options in GFIX for Firebird 2.0).

> The other problem is the listening port - I don't want to use custom
> ports. gds_db service has a port registered, let's use it.

Changing ports is only necessary on coexhistence.


> A good book for subversion is at http://svnbook.red-bean.com/
> debian packaging http://www.bg.debian.org/devel/join/

I will look them up.

> There is a lot to read, but don't panic and arm yourself with
> patience. Please read below for more ways to help.
>
> Debian release behaviour is maybe different from what you expect.
>
> http://datacircle.org/archives/2006/01/26/how-debian-releases-work/
>

I know that, and that's why I consider to have the deb file so important, 
because we could install a new version o FB by dpkg without have to wait 
until a package become "Debian stable". I do this all the time with tar.gz 
file...


> No one can stop us from providing backported packages, though
> (packages with new versions, built to be installable on stable). There
> is even a semi-official site, dedicated to this - backports.org.
>
> I've never built a 1.5 firebird packages for sarge, since I personally
> use a mix of stable, testing and unstable (even for servers; Sometimes
> I regret it) and second, no one asked for this :) There are no big
> technical difficulties of preparing a backport, really.
>
> Now that Etch release is near and 2.0 packages won't be there, I
> certainly will try to packport them.
>
> I'll need help in two areas - discussing handling different versions
> (which we already do), and testing new packages, which are not ready
> yet, but will be soon, I hope.
>

I don't have either much available time nor experience in C++, but if I can 
help, you can count on me.

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: Friday, November 24, 2006 1:52 PM
Subject: Re: [pkg-firebird-general] Re: Being a beta tester for Firebird 
2package on Debian

> Hi, Valdir,
>
> Valdir Marcos -=| 24.11.2006 06:00 |=-
> > I agree with you about the coexistence.
>
> Good ;)
>
> > 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)?
>
> I can try to rename firebird2 to firebird-1.5 and firebird2-2.0 to
> firebird-2.0, yes. Renaming packages with complicated
> inter-dependencies is not my favourite, but I agree this is the way to go.
>
> > Again, could the directories be "/etc/firebird15" and "/etc/firebird20"?
>
> I'd prefer /etc/firebird/1.5/  /etc/firebird/2.0 etc
>
> > Could this instalations create the users and groups "firebird15" and
> > "firebird20"?
>
> Why separate users/groups for each version? What's wrong with single
> user? All apache versions use the same user - www-data.
>
> his 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.
>
> Not simultaneously. Two reasons:
>
> Some binaries are in /usr/bin and I don't want to have
> /usr/bin/gfix-1.5 and /usr/bin/gfix-2.0 - it's ugly and an overkill
> having in mind that the typical installation will have only one
> version installed.
>
> The other problem is the listening port - I don't want to use custom
> ports. gds_db service has a port registered, let's use it.
>
> > 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?
>
> I am not sure how to start :)
>
> A good book for subversion is at http://svnbook.red-bean.com/
>
> As of debian packaging, it is very wide area; I am still learning :)
> You may want to take a look at http://www.bg.debian.org/devel/join/
> There is a lot to read, but don't panic and arm yourself with
> patience. Please read below for more ways to help.
>
> > 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...
>
> You're talking about 2.0, I guess (1.5.3 is in Debian/testing).
> Please note that the stable policy is very restrictive. Once released,
> stable accepts only very critical changes - security fixes, grave bugs
> etc. In no case stable can accept a new upstream release.
>
> Debian release behaviour is maybe different from what you expect.
>
> In general any new version of a package (upstream release or debian
> revision) enters unstable first. Then after certain period of time it
> enters "testing", but only if the package has no release-critical
> bugs. Then, once in a while, release managers declare a new Debian
> "stable" release, containing packages from "testing". This "stable" is
> then frozen for changes.
>
> Here's an article about this
> http://datacircle.org/archives/2006/01/26/how-debian-releases-work/
>
> No one can stop us from providing backported packages, though
> (packages with new versions, built to be installable on stable). There
> is even a semi-official site, dedicated to this - backports.org.
>
> I've never built a 1.5 firebird packages for sarge, since I personally
> use a mix of stable, testing and unstable (even for servers; Sometimes
> I regret it) and second, no one asked for this :) There are no big
> technical difficulties of preparing a backport, really.
>
> Now that Etch release is near and 2.0 packages won't be there, I
> certainly will try to packport them.
>
> I'll need help in two areas - discussing handling different versions
> (which we already do), and testing new packages, which are not ready
> yet, but will be soon, I hope.
>
>
> Kind 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
>
>