--- Begin Message ---
- To: Debian Bug Tracking System <submit@bugs.debian.org>
- Subject: lighttpd: reorganize lighttpd binary packages to reduce dependencies (ldap/mysql) and package count
- From: Helmut Grohne <helmut.grohne@intenta.de>
- Date: Tue, 18 Dec 2018 09:55:34 +0100
- Message-id: <20181218085533.47me5oaufxjrjowt@laureti-dev>
Source: lighttpd
Version: 1.4.52-1
It has come up that lighttpd's binary packages are organized
suboptimally. I'm creating this bug report to discuss a better
organization and have X-Debbugs-Cced some interested parties. Please
forward the bug to other interested parties that you may know of.
Problem #1:
Some upload since stretch added the mod_vhostdb_* modules including
mod_vhostdb_ldap.so and mod_vhostdb_mysql.so. Therefore lighttpd now
depends on libldap and libmariadbclient. That produces an unreasonable
installation size for embedded uses. Multiple people (including Stefan
Bühler, Glenn Strauss and myself) have requested to shrink this.
Problem #2:
lighttpd presently produces 11 binary packages. That's quite many for an
otherwise small package. Adding binary packages has a metadata cost to
the Debian archive that affects everyone (not just lighttpd users). We
should seek to reduce the package count.
Are there more problems?
Fixing the first problem likely involves making the second problem
worse. We should seek to avoid that.
With regard to fixing this my first proposal builds on the existing
practise to put mod_foo.so into lighttpd-mod-foo: Let every binary
package build from src:lighttpd have Provides for the modules that it
ships. For the present lighttpd-mod-* packages, no Provides are needed.
Only the main lighttpd package needs a pile of provides. A README.Debian
should explain that you should use these virtual packages in Depends
rather than e.g. "Depends: lighttpd (>=
$version_that_introduced_mod_foo)".
Given that lighttpd modules are comparatively small (some tens of KB), I
suggest that grouping them by their main dependency would make sense.
The fairly obvious consequences would be:
* lighttpd-modules-mysql: mod_authn_mysql, mod_mysql_vhost,
mod_vhostdb_mysql
* lighttpd-modules-ldap: mod_authn_ldap, mod_vhostdb_ldap
* lighttpd (base package): mod_access, mod_accesslog, mod_alias,
mod_auth, mod_authn_file, mod_cgi, mod_dirlisting, mod_evasive,
mod_evhost, mod_expire, mod_extforward, mod_fastcgi,
mod_flv_streaming, mod_indexfile, mod_proxy, mod_redirect,
mod_rewrite, mod_rrdtool, mod_scgi, mod_secdownload, mod_setenv,
mod_simple_vhost, mod_sockproxy, mod_ssi, mod_staticfile, mod_status,
mod_uploadprogress, mod_userdir, mod_usertrack, mod_vhostdb,
mod_wstunnel
* The modules mod_authn_gssapi, mod_cml, mod_geoip, mod_magnet,
mod_trigger_b4_dl and mod_webdav presently have their own binary
packages and they each have significant library piles. Maybe it is
best to leave these as is.
* The remaining modules are mod_compress, mod_deflate and mod_openssl.
These pull zlib1g, libbz2-1.0 and libssl1.1. At least the first two
are transitively essential already and mod_openssl seems to be very
popular, so it likely is best to leave them with the main binary
package.
Resulting changes:
* Merge lighttpd-mod-authn-mysql and lighttpd-mod-mysql-vhost together
into lighttpd-modules-mysql.
* Rename lighttpd-mod-auth-ldap to lighttpd-modules-ldap.
* Add 3 transitional dummy packages for the removed/renamed packages.
* Move mod_vhostdb_mysql and mod_vhostdb_ldap to the new packages.
-> mysql and ldap depends removed from lighttpd
-> +2 binary packages for buster
-> -3 binary packages for bullseye
-> Due to Provides (see above), rdeps don't have to change.
Then Stefan and Glenn proposed adding new modules:
* mod_vhostdb_dbi
* mod_vhostdb_pgsql
* mod_authn_pam
* mod_authn_sasl
Here it is less clear how to organize them. mod_cml and
mod_trigger_b4_dl each use libsasl2 (via libmemcached).
mod_vhostdb_pgsql is likely the only module that links postgres, so
likely it'll deserve a binary package.
How bad would it be to simply not ship these four packages in buster (as
is presently the case) and add them for bullseye? Which ones do we
really need for buster? Did I miss anything?
Please reply in a timely manner to allow implementing as much of the
changes as possible before the buster release.
Helmut
--- End Message ---