[pkg-firebird-general] Bug#310609: libfirebird2-super: firebird.msg is missing

[Damyan Ivanov]

Hi Francesco,

(This became rather long, with (sort of) disagreement in the
beginning, to agreement and proposed solution at the end)

Francesco P. Lovergine wrote:
> On Tue, Jun 20, 2006 at 11:38:59PM +0300, Damyan Ivanov wrote:
>> I've decided to go on package split.
>>
>> A new package, firebrid2-common, Arch: all, will contain firebird2.msg,
>> firebird.conf, aliases.conf, logrotate conf, and log purging suport.
>>
>> All server and library packages will depend on it. This will
>> additionally satisfy libfbembed's need of aliases.conf, firebird.conf
>> and logfile.
>>
> 
> Did you consider that in order to avoid a deprecated dependency loop 
> you will  have to require the user to remove -common autonomously at 
> main package remove? Indeed I think you will need a versioned 
> dependency on the -common package. But the reversed one is deprecated.
> I'm not so sure that a -common package with nothing but configuration 
> files is a right answer.

The whole mess comes that firebrid has two flavours (super and
classic) that share some files, but must have their own variant of other.


First, what is firebird.msg.

It is a binary-compiled, architecture-independent b-tree file that
maps firebird error codes to strings. It is used by an API function to
construct error messages from error codes. This API function is not
used on server side, but only on client side. Server works with the
codes and transmits them to the client, where they're supossed to be
decoded and shown to the user. Thus, despite the short plan quoted
above, I intent to not make server packages depend on the new -common
package.

Problems I am trying to solve:
(1) 3rd party programs that have only client packages installed can't
format messages
(2) embedded access programs (using libfbembed) can't format messages
(3) client-only installs currently get firebird2-server-common
dependency, cluttering the system with 2+2M of security database.
(default-security.fdb is 2M and gets copied to
/var/lib/firebird2/system on new installs)


The plan in details:


Current state:

Package: firebird2-{super,classic}-server
Depends: firebird2-server-common, libfb{client,embed}1

Package: firebird2-utils-{super,classic}
Depends: firebird2-server-common, libfb{client,embed}1

(super depends on client, classic - on embed)

Instead of making libfb{client,embed}1 Depends:
firebird2-server-common, I intent to split parts from
firebrid2-server-common that are not server-only-related into a
separate package and make library packages depend on it.

firebird2-common would contain (60k compressed)
- /etc/firebird2/aliases.conf
- /etc/firebird2/firebird.conf
- /usr/lib/firebird2/firebird.msg (moved to /usr/share and symlinked
in /usr/lib, since it is arch-independent)
- log stuff - logrotate config and log purging

Remaining in firebird2-server-common are (400k compressed, 2.6MB
uncompressed):
- security.fdb handling
- help.fdb
- UDFs
- intl


Benefits of the split:
- give a client/library-only installation a chance to work with only
libfb{client,embed}1 and firebird2-common installed without the
clutter of -server-common.


As of dependencies, I see no loop. In the -9 upload:
(shlibs and other dependencies not shown)

Package: firebird2-common
Replaces: firebrid2-server-common (<< 1.5.3.4870-9)
Conflicts: firebrid2-server-common (<< 1.5.3.4870-9)

Package: libfb{client,embed}1
Depends: firebrird2-common

Package: firebird2-utils-{super,classic}
Depends: firebird2-common  (firebird2-server-common dropped)

Package: firebird2-{super,classic}-server
Depends: firebrird2-server-common, firebird2-common

This has the benefit that an application using embedded access via
libfbembed1, as well as any 3rd party applications that need
libfbclient1 will get firebird.msg.

Thinking again, I see a possible failure on a utils-only install
upgrading only firebird2-server-common (currently depended on by
-utils-*). This will cause firebird.msg to disappear.

Do I have to guard from such partial upgrade? Perhaps yes, since
firebird2-common will be in NEW for sime time...

This could be solved by a

Package: firebird2-server-common
Depends: firebird2-common

or

Package: firebird2-server-common
Conflicts: firebird2-utils-{super,classic} (<< 1.5.3.4870-9),
libfb{client,embed}1 (<< 1.5.3.4870-9)

(i.e. conflicts with old revdeps, IIUC)
This makes four packages in Conflicts, which is ugly, but can be
dropped after etch release.

First approach look better, since it is less inter-package relations,
in expecne of duplicating firebird2-*-server dependency on
firebird2-common.


An even more radical approach would be to put firebird.msg alone in a
separate package and declare appropriate dependencies in
libfb{client,embed} and firebird2-utils-*.

This helps a bit (and clutters Packages) plus the benefit of having a
place to put tralsnated message files (now only present in version 2.0
release candidate), but does not avoid the split of firebird.conf,
aliases.conf and log file handling in firebird2-common.



I'd very much like to read your opinion on proposed aproaches.


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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
Url : http://lists.alioth.debian.org/pipermail/pkg-firebird-general/attachments/20060621/e0bb25a0/signature.pgp