Number of berkeley db packages reduction
I would like to coordinate reduction of BDB packages since I took the
unhappy job (as I could expect) to maintain BDB in Debian after Clint
have orphaned them.
The main issue which I have encountered (in cyrus-imapd) is that the
change from 4.x to 5.x introduces code changes, because the packages
check for 4 + something version number. The fix is easy (I can help
with that if needed), but it still some work which needs to be done.
My suggestion is:
1) Fill bugreports against all packages linking to db4.6, db4.7 and
db4.8 to upgrade build depends to libdb-dev (>= 5.1) or at least to
libdb5.1-dev (which makes later transition harded).
1a) Optionally link with just -ldb and not -ldbX.Y (linking to
specific BDB versions generate a lot of problems, since f.e.
cyrus-imapd will happily include 5.1 headers and link to libdb4.7)
2. After some time rebuild the db4. to not generate -dev
packages, but to keep db4.-util package available and increase
3. After some time rebuild the db4. to not generate libdb4.Y
packages, but keep db4.-util package available and increase
severity to RC
Release next stable with just one libdbX.Y-dev (and libdb-dev) and all
dbX.Y-util which were included in current stable.
For stable+2 reduce the number to just two version - current -dev and
dbX.Y-util for stable+1 upgrades.
I know this could cause a lot of pain, but I think the keeping of X >
2 versions of BDB is not sustainable from a long term PoV.
I would like to coordinate this with a release team.
Also any help would be much appreciated, I am already too overloaded,
and I took BDB maintainership just because of cyrus-imapd sake, so if
there are any other heavy BDB users, please come and join the
packaging team (especially if you use BDB transactional mode).
P.S.: Please Cc: me since I am not subscribed to debian-devel
Ondřej Surý <firstname.lastname@example.org>