Hi there, There is a package in Debian: modsecurity. This is a library and provides a -dev and a runtime packages (libmodsecurity-dev, libmodsecurity3t64).
ModSecurity is an open source WAF (Web Application Firewall) "engine". You can write rules (in a special language called "SecLang") and control HTTP traffic with them. To use it the HTTP server/proxy needs a "connector". Actually there is only one stable connector, for Nginx - this is also part of Debian. ModSecurity has a special feature: users can store data in "collections". Eg. if you want to protect your application against DoS, you can store the client IP's in a collection and store the number of requests. After a previously set time, these data are automatically deleted. Here comes the problem: libmodsecurity3 has two types of collection stores: in-memory and LMDB. It's VERY important: you MUST decide the type of choosed backend in compilation time, later you can't change it in runtime! If you choose the in-memory storage, you will lose your stored data when you restart the web server, but it does not need any dependency. If you use LMDB then data will be preserved after restart - but there was a missing feature: you couldn't remove the data from storage, because that feature wasn't implemented. If you wanted to remove the data you should have removed the database itself. This is why we chose the in-memory solution when creating the package for Debian. But in the meantime the developers implemented the missing feature, so now the engine is ready to use LMDB too. I don't want to force users to use LMDB, rather I prefer to deliver two library packages: one with in-memory and one with LMDB. I couldn't find any guideline in Debian packaging documentation but found the libcurl-dev as a pattern. Based on that I created a simple test package to emulate the behavior (compiling libmodsecurity takes more time - this package is very simple and anyone can build few seconds): https://salsa.debian.org/airween/testlib/ This is only one source and produces 4 binary packages: libtestlib0_0.0.0-1_amd64.deb libtestlib0-lmdb_0.0.0-1_amd64.deb libtestlib-dev_0.0.0-1_amd64.deb libtestliblmdb-dev_0.0.0-1_amd64.deb Before I send the modified package structure, I would like to ask few questions: * in this case the API hides the differences between two solutions; Is it enough to make one -dev package and two different runtime packages? * are the names acceptable "libmodsecurity3t64" and "libmodsecurity3-lmdbt64"? * based on the test package, are there any comments or advice to be considered? Thanks for all, a.
