gdbm makes building difficult on Solaris

[zanchey]

The use of gdbm has made compiling PulseAudio a bit interesting on Solaris.

gdbm is not shipped by Sun and is not available as an optional SUNW package. It is available from third-party distributors (e.g. blastwave.org) but this requires users to set up a secondary package installation tool.

ndbm is a possible replacement.

Possible approaches:

1. Add a note in the documentation to say that PulseAudio requires gdbm, and that Solaris users will need to download and install it separately.

Presumably autotools will pick up libraries from /opt/csw/lib etc.

2. Convert modules/module-device-restore.c to use ndbm if gdbm is not available.

Presumably requires a bunch of #ifdef-ing, which is potentially ugly.

3. Convert modules/module-device-restore.c to use ndbm. If gdbm is available, link with -lgdbm -lgdbm_compat to use GDBM's NDBM compatibility layer.

Possible issues if there are features in GDBM unsupported by NDBM (e.g. there is no way in NDBM to set the cache size, AFAICT). Files created by NDBM and GDBM-in-NDBM-compat-mode are incompatible but the use of the host name in creating the file probably negates this.

(I am happy to work on a patch using methods 2 or 3, but would appreciate some guidance as to which would be more acceptable to the PulseAudio project.)

[lennart]

I must admit that I expected that picking gdbm would eventually burn me.

The requirements towards a db interface in PA are very soft: we don't need locking, we don't need particular NFS safety (there's always only exactly one process on exactly one machine accessing a file), we don't need CPU independance or portability, nor do we need any other special functionality.

Here's my suggested solution. There should be a little abstraction src/pulsecore/database.h that abstracts over the database interface. Should be very very simple and should fix all API issues gdbm exposes:

typedef struct pa_database pa_database; typedef struct pa_database_datum {

void *data; size_t size;

} pa_database_datum;

pa_database* pa_database_open(const char *fname, pa_bool_t for_write, mode_t mode); void pa_database_close(pa_database *db); void pa_database_put(pa_database *db, const pa_database_datum *key, const pa_database_datum *data); int pa_database_get(pa_database *db, const pa_database_datum *key, pa_database_datum *data); int pa_database_remove(pa_database *db, const pa_database_datum *key); int pa_database_first(pa_database *db, pa_database_datum *key); int pa_database_next(pa_database *db, pa_database_datum *key); void pa_database_sync(pa_database *db); void pa_database_vacuum(pa_database *db);

Then we could provide multiple implementations of this for different systems: database-gbdm.c, database-ndbm.c and so on.

Setting the gdbm cache size is used in PA to cut down a bit of gdbm's memory waste. This issue can be ignore for an ndbm backend.

Patches welcome of course ;-)

[dennis]

i install my linux system from source since a decade now and never needed to install gdbm. it is also one of the worst choices for storing data because of a weak hash algorythm and data loss in certain situations. this may not be a problem to pulseaudio. but it sounds weird to me that a soundserver is enforcing the installation of a certain db. i refuse to install gdbm and thus refuse to install pulseaudio. can't you at least choose a db more widely used today? for example, sqlite is a must-have, no way around it. yes, it can do more you need but it is a neccessity provided on just every system running modern software and more sane (except of using SQL as feed).

actually, if your needs are so soft, doesn't a plain file do it too?

regards, dennis

[lennart]

dennis, please do not change the priority/type/severity of a bug. It is up to us, the maintainers to priorize and categorize things. Thank you very much.

gdbm is the GNU implementation of the BSD dbm interfaces. dbm has been an integral part of every UNIX system. It is a simple and small binary non-relational embedded database system, that has been shipped with Linux systems since before time began. As such it fits our goal perfectly. The only drawbacks are that it is not that common on non-Linux systems.

Also, you might be surprised, but I am not particularly scared if you tell me that you refuse to install gdbm, you know?

[zanchey]

database.h (starting point only :-)

[zanchey]

I did give this a bit of a crack, but I'm not much of a C programmer, and I'm not sure how you want to handle errors inside the various functions.

.h file is attached as a starting point; if someone more experienced (Lennart?) was to give database-gdbm.c a go, I'd be more comfortable writing the NDBM backend and perhaps removing the existing GDBM code from the various modules.

Obviously neither GDBM or NDBM are available on Windows; it might be interesting to write a Win32 INI-file implementation or something similar.

http://avahi.org/browser/avahi-utils/stdb.h and http://avahi.org/browser/avahi-utils/stdb.c may be useful references for outside contributors.

[lennart]

I have abstracted this now in PA git. There is now a gdbm and a tdb backend. If you want to add more (ndbm?) you are welcome, it should be very very easy.

Closing since tdb is no longer a hard dep.