No dbm

[roarde]

While there is gdbm, it's intentionally built without compatibility options. See its SlackBuild.

Programs intended to compile not only on Linux, but also on other OS's may be looking for symbols as found in dbm.h (usually) or ndbm.h. Even if the program's source knows about gdbm, it will look for the "compatibility" part.

Observed while trying to build nmh.

[roarde]

Found gdbm "compatibility bugfixes" that came in since the 1.11 (latest) release. http://git.gnu.org.ua/cgit/gdbm.git/

[roarde]

For nmh (and probably everything else), the dependency is solved by our 'db44' package. As shipped, vl71 has 'db' at version 5.x which does not solve the dependency. 5.x conflicts with 4.4.

Just making the note while I have time.

[roarde]

I'm hacking on this.

https://bitbucket.org/roarde/vl71-roarde/branch/db

As of now, db44 is there; a db53 is needed; a new 'db' package is needed to tie it all together and make db44 the default db. Packages needing to build against db53 will need to include /usr/include/db53/db.h etc.. Existing packages built against existing db, which is db-5.3.x, should still work because /usr/lib(64)/libdb*-5.3.* will still be there.

When finished, dbXX and db packages will not conflict with each other.

[roarde]

A first proposal is ready. https://bitbucket.org/roarde/vl71-roarde/branch/db "db, db44, db53: new layout first demo"

Haven't had a chance to install and test the packages yet, except for installation to a subdirectory under $HOME. That's coming up as soon as I can get there.

Sorry about the slowness. It's all I can do and, given real life, more than I should. I'm afraid this tempo or slower is what you should expect now.

[roarde]

The above proposal has been scrapped. Anything that might result in a change of which Berkeley DB version an application uses risks loss or corruption of user data, because the two existing DB versions are sometimes both used in the same application. Recovery of one version's data files by an older version is tricky.

Instead, I've offered pull request #179, which provides a symbol-specific version of Berkeley DB that uses subdirectories of /usr/include and /usr/lib for everything except the C interface, which has a minor-version-specific filename suffix; and the utility binaries, which are also given that suffix. No chance of conflicting symbols, and updated or newly built applications will not use these libs unless very specifically told to do so.

Since the new package is db4-based, almost everything that cannot use db5 (which is the default already, like it or not) can use either existing db44 (suggested, but missing its headers!) or this new package.

If the pull request is accepted, my opinion is that this issue is closed. I'd say not "resolved", maybe "wontfix"; but closed.

[roarde]

Some applications may use "db" 5.3's dbm, others cannot. Those might use db48-unique or db44.