db: check slackbuild

[roarde]

7.2 not installed. Report comes from reading db.SlackBuild.

[Moises Henriquez]

Did you mean it is not installed by default on 7.2 or that the package is bad? The build logs show the package is not empty for sure

./
lib/
install/
install/doinst.sh
install/slack-desc
install/slack-required
usr/
usr/lib/
usr/lib/libdb_cxx-6.1.so
usr/lib/libdb-6.1.so
usr/lib/libdb.a
usr/lib/libdb_cxx-6.1.a
usr/lib/libdb_cxx.a
usr/lib/libdb-6.1.la
usr/lib/libdb_cxx-6.1.la
usr/lib/libdb-6.1.a
usr/doc/
usr/doc/db-6.1.26/
usr/doc/db-6.1.26/db.SlackBuild
usr/doc/db-6.1.26/LICENSE
usr/doc/db-6.1.26/README-DOCS
usr/doc/db-6.1.26/README
usr/include/
usr/include/db/
usr/include/db/db_cxx.h
usr/include/db/db_185.h
usr/include/db/db.h
usr/bin/
usr/bin/db_dump
usr/bin/db_verify
usr/bin/db_archive
usr/bin/db_recover
usr/bin/db_log_verify
usr/bin/db_tuner
usr/bin/db_deadlock
usr/bin/db_load
usr/bin/db_printlog
usr/bin/db_stat
usr/bin/db_hotbackup
usr/bin/db_upgrade
usr/bin/db_checkpoint
usr/bin/db_replicate

This is from http://vlcore.vectorlinux.com:8010/builders/db/builds/11

[Former user]

which db package? db = 6.1.26 db44 = 4.4.20 db53 = 5.3.21

[roarde]

Just downloaded the latest 'db' package from untested and exploded it into a directory.

grep '(.*)' install/doinst.sh turns up links to libdb-5.3*, which is what I'm referring to. The relevant lines from the sb:

# Some things might look for these libraries by other names.
( cd $PKG/usr/lib${LIBDIRSUFFIX}
  ln -sf libdb-5.3.a libdb-5.a
  ln -sf libdb-5.3.a libdb5.a
  ln -sf libdb_cxx-5.3.a libdb_cxx-5.a
  ln -sf libdb-5.3.so libdb5.so
  ln -sf libdb-5.3.so libdb.so
)

Also, if a libdb is wanted "before /usr is mounted", having a link in /lib will do no good. Either cp or give up on this.

[Former user]

is this sorted by your db-unique package?

[roarde]

Short answer: not for 7.2, no.

db48-unique should not be copied from 7.1 to 7.2. That package does address some of the issues above, but the solution for 7.2 can be much simpler and more straightforward than for the already-released 7.1.

Having db-4.8 as the default Berkeley DB implementation for 7.2 has been favorably discussed in irc. I'm setting up an example of that for examination and possible trial. That db-4.8 package will not use the unique prefixes, but the binary utilities in /usr/bin will still have suffixed filenames to prevent scripts or such from using the wrong version of a utility. Just in case some users have data that actually does need dump and retrieval, I'll produce a db53 package which will follow 7.1's db48-unique fairly closely in form, but won't have "-unique" appended to the package name. The name distinction was done in 7.1 to show that the new db48 was different in form from the existing db44. For 7.2, any implementation other than the default will get unique symbol prefixes and have only libdb-N.N. libs linked back to /usr/lib.

What I've suggested for 7.2, I already have for 7.1 but didn't offer it there. Some minor edits, the tougher check of dependencies, then it's ready for you to look at or try on 7.2. Shouldn't be all that long.

[hata_ph]

From what i see there is 2 way to solve this db version problem in 7.2.

1. Follow Arch way, use 1 unified version of db.
2. Follow slackware way, create multiple dbxx pkgs with different version and no more using the default db pkgs name. Only apply the need dbxx pkgs for dependency.

[roarde]

Exactly one db implementation is the right way to go. Arch should have chosen a db-4 instead of a db-5, though. Too many changes to calls between the two that dependent applications haven't caught up with yet. Went a bit further in their package browser and noticed they didn't have nmh, mh, or mailx, all of which use db or dbm of some sort. Build troubles against db-5, maybe?

Use only db-4.8 for 7.2. Call that package 'db'.

That leaves only one problem. Very few users will experience it, maybe none. But we should provide for it. After some study, my prediction is that any existing databases users bring over from a previous installation (few, if any) will "just work", or will auto-convert with only a warning and no data loss. If I'm wrong, the worst case is what the app will think is corruption. To handle that, make one package that includes both db-53 and db-44 (7.1 used both). Set both of them up similar to 7.1's recent db48-unique, except copy all of the libdb*-N.N libraries to /usr/lib -- I now realize that's safe. The purpose here is to provide the command-line utilities for those versions. The utility filenames will be suffixed with -N.N, as will those utilites that come with the db package; no one will use the wrong one in confusion, though they're slightly harder to find. Suffixing the filenames of these utilites has now become fairly common.

Call the combined Berkeley DB 4.4/5.3 package 'bdb-recover'. My thought is calling it 'db-recover' might lead people to think it was needed to recover any Berkeley DB files of any version. And I worry that naming it "db44" or especially "db53" would just invite people to build with it, again mixing database types.

Note that, at least for packages that have been built, none of them have a 'db' dependency, rather it's 'db44' (a change to bogofilter is offered and pending at this writing). There are still a very few that have 'db' (and not '!db') in their MAKEDEPENDS, but even those now depend on db44 and not db once they're built -- probably due mostly or entirely to the change in apr-util.

[roarde]

What I'm doing on this is at https://bitbucket.org/roarde/vl72-roarde/branch/db .

First was setting up db44 temporarily so that packages still having that dependency can link and/or build. No pull request to VLCore is offered yet. Will replace the 'db' package with one set up to be THE db for 7.2 using db version 4.8. Then edit sb's which have db44 in MAKEDPENDS to use "db" instead. Then offer pull request.

Next would be to trigger rebuilds of apps that have db44 in their slack-required, and try to include those that don't, but may be affected. Scan the results for use of db44 and make changes to remove that use. Wait a bit, remove the db44 package, wait some more.

Last step is not time-critical, but needs to be done before release. Note: I'm not suggesting whether or not any Berkeley DB package needs to be on the release and/or buildbase ISO's, rather that they should be in the repo at release time. Main thing here is a DB package (or two) that contain db44 and db53 utilities in case users need to do recovery on old files.

I still think a combination package for that is best, still in favor of the name "bdb-recover". I have come to favor naming the utilites as in the present db44 package, like renaming "db_load" to "db44_load". Not "db_load-4.4" as I suggested and as Ubuntu has it.

For those who have been following but not commenting, there're still pros and cons of various elements being discussed. I need your comments and input, and having any consesus that might develop would help.

[roarde]

Proposal for the db package is up now on the "db" branch of my fork (URL in previous post).

Two things I forgot to mention before:

The proposed "db" doesn't use db185 compatibility. Postfix and a few other programs misbehave when db has that feature. Ndbm and dbm support are still there, which means that any application not satisfied by this package needs db1. I doubt there are any of those. If there are, gdbm has recent patches which are claimed to overcome the Postfix problems; perhaps historical support can be turned on there. It would be good not to have to support db1 at all because it adds complexity.

Second, documentation says that RPC was removed from 4.8, so that configure flag was removed from the sb. We have RPC apps, but I don't think those are using Berkeley DB for that interface. Some of the RPC apps from 7.1 do list db (which is 5.3 in 7.1) in their slack-depends. I couldn't find RPC apps from 7.1 with db44 in their dependency chain. Db 5.x definitely doesn't do RPC; there're some hints that it may still be there, undocumented, in 4.8.

If an RPC application won't build or work properly when RPC support isn't available from Berkeley DB, perhaps those apps should be rebuilt to use a different provider. Again, the support hasn't been in new BDB releases for five years.

[roarde]

The issue that started this post, errors in the "db" slackbuild, still remains. If I knew what Berkeley DB version is wanted, I could plug it in to the existing script and fix those errors. Then this issue could be closed, though concerns remain about db in general.

Other than that, I've stopped working on Berkeley DB. The branch on my fork will remain there for the interested.

[Moises Henriquez]

The db package has been removed as of A0.3.7 (see tag A0.3.7). Everything that needs a db implementation can use either db44 (included in the iso) or db53 (available on the repositories.)