Bug 2148571

Summary:	RFE: Provide package that supports sqlite
Product:	[Fedora] Fedora	Reporter:	W. Michael Petullo <mike>
Component:	bogofilter	Assignee:	Adrian Reber <adrian>
Status:	CLOSED DUPLICATE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	low	Docs Contact:
Priority:	low
Version:	37	CC:	adrian
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2023-09-16 15:13:24 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description W. Michael Petullo 2022-11-26 01:11:05 UTC

Description of problem:
Fedora's bogofilter package makes use of the Berkeley DB backend. I recently migrated my server-side bogofilter install from OpenWrt to Alpine, and I found that the Alpine bogofilter packages uses the SQLite backend. This is incompatible with Fedora, which is where I generate my wordlist database.

Would it be package a version of bogofilter that uses the SQLite backend?

Version-Release number of selected component (if applicable):
bogofilter-1.2.5-9.fc37.x86_64

How reproducible:
Every time

Steps to Reproduce:
1. Generate wordlist on Fedora with "bogofilter -d ~/mail -M -s" and "... -n".
2. Deploy wordlist.db to server.
3. Allow bogofilter to process mail on server.

Actual results:
Running bogofilter results in:

bogofilter[18946]: cannot compile SELECT value FROM bogofilter WHERE key=? LIMIT 1;: file is not a database_

Remember to register some spam and ham messages before you
use bogofilter to evaluate mail for its probable spam status!

Expected results:
Bogofilter should process mail.

Comment 1 Adrian Reber 2022-11-28 07:38:41 UTC

I would like to change the bogofilter backend DB for a long time already, but the problem is that bogofilter can only be built with one backend. If we switch to anything else than the current backend all existing users cannot use their databases anymore.

Not sure how to best switch to sqlite without breaking existing users.

Comment 2 W. Michael Petullo 2022-11-28 14:38:55 UTC

I started a discussion with the upstream project at https://gitlab.com/bogofilter/bogofilter/-/issues/9.

Comment 3 W. Michael Petullo 2022-12-05 20:59:39 UTC

Matthias Andree (upstream) does not intend to extend bogofilter to support multiple backends or write a converter. I started to think about how to build two sets of binaries, but I have not yet come to a good solution. Using "%configure --disable-rpath --with-database=sqlite3 --program-suffix=-sqlite" is useful, but rpmbuild deletes the work of a previous configure/build cycle before starting another. Also, the install target is separate from the build target, so it will install only the binaries from the latest configure/build.

Ultimately, it would be nice to have, e.g., a bogofilter-sqlite package that provides a set of binaries that make use of the SQLite backend.

There must be an existing package somewhere that does this. I am presently looking for such an example.

Comment 4 Adrian Reber 2022-12-06 14:37:40 UTC

We would probably need to build bogofilter twice. At least have a bogoutil binary to dump the old database and import it into the new database. This still means that every user has to do it manually.

If you look at the debian package it seems they have multiple sub-packages built for many different backends. That would be a possibility but switching the database format is probably still a manual step.

Comment 5 W. Michael Petullo 2022-12-06 15:08:31 UTC

Adrian, I agree with all of you points. I think the Debian approach is a good model. What I have not yet found is an example of a Fedora package that builds its software artifacts two or more times. I started to put something together, but I ran into the problems I mentioned in comment #3. Do you know of any other packages that build twice?

Comment 6 W. Michael Petullo 2022-12-08 02:28:15 UTC

It looks like the vim package might serve as a good example. The vim .spec runs %configure more than once, and it moves things around to cause the %make_install to do most of what is needed. The duplicate binaries are copied into place outside of the %make_install.

Comment 7 W. Michael Petullo 2022-12-08 03:38:50 UTC

The pull request at https://src.fedoraproject.org/rpms/bogofilter/pull-request/1 modifies bogofilter.spec to build two sets of binaries, placing one of them in a bogofilter-sqlite package.

Comment 8 W. Michael Petullo 2023-09-16 15:13:24 UTC


*** This bug has been marked as a duplicate of bug 1788486 ***