Packaging db-5.1.19
Bug #644670 reported by
Jeff Johnson
This bug affects 1 person
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| clefos |
Confirmed
|
Medium
|
herrold | ||
Bug Description
Berkeley DB 5.1.19 was release over the last 2 weeks.
A simple rebuild, with /usr/include/db51, and including
a new subpkg for the new dual access -ldb_sql-5.0 libraries,
would be nice.
Note that there are dtrace/systemtap hooks that might be meaningfully
enabled these days too.
Ditto for db-5.0.26, also with a db-sql library.
All pretty much no-brainers _EXCEPT_ watch out for
the "partial static linking", i.e. -ldb_sql includes an
entire copy of Berkeley DB within. WORKSFORME,
but does lead to some additional Bloat!
Also: compat-db* to retire the sonames/paths used on RHEL6/RHEL5,
so that there is a devel path forward is useful.
| tags: | added: compat-db db50 db51 packages |
Revision history for this message
| Jeff Johnson (n3npq) wrote | #1 |
| Changed in clefos: | |
| importance: | Undecided → Medium |
| assignee: | nobody → herrold (herrold) |
| status: | New → Confirmed |
To post a comment you must log in.
Extra credit useful enhancements:
1) tools/db_tool.c from @rpm5.org includes all tool functionality,
but requires only a single "partial static link" thereby removing
much of the bloat.
2) use alternatives to easily flip between versioned executables.
Specifically, burying the version into the tool names like
/usr/bin/dbXY_*
is stoopidness. Better would be a version specific .../bin
directory, and use alternatives to switch executables in/out.
The -I/usr/include/dbXY convention is mostly okay (having
a single /usr/include/db alternative link is just asking for
bug reports), but any of the usual hinting with db-config/
likely helps targeting multiply installed versions of Berkeley DB while developing.