Bug#916750: lighttpd: reorganize lighttpd binary packages to reduce dependencies (ldap/mysql) and package count
Hi Glenn,
On Tue, Dec 18, 2018 at 11:12:30AM -0500, Glenn Strauss wrote:
> > 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.
>
> IMHO, it appears that the origin of these issues is the metadata cost,
> and not that lighttpd is modular. It appears the metadata costs are
> the tail wagging the dog for package design decisions. That is most
> unfortunate.
Yes, it is the metadata cost. A number of people have tried fixing it,
but unfortunately that proved to be difficult. So yes, we are now
working around that. We'll have to find some trade-off.
> Perhaps for Buster, all the new packages should be removed, except
> those split from existing lighttpd core (mod_openssl) and from mod_auth
> (mod_authn_file, mod_authn_ldap). Hopefully, Debian will address the
> metadata cost scaling issue in a future Debian release.
Removing packages does not make much sense as those are already there.
My question was aiming at which of the new modules (pam, pgsql, dbi,
etc.) we should add. If the answer is "all", so be it.
I doubt that anyone will fix the metadata cost issue anytime soon.
> I still think it reflects poorly on Debian that lighttpd in Debian
> will be crippled due to Debian packaging scaling limitations.
There's no hard rule on the package count. I'm just trying to figure out
a reasonable trade-off and push back on blindly adding many packages. If
we end up increasing the package count for sound technical reasons, so
be it.
> While I would like to see mod_openssl as its own package for the
Why do you want to split off mod_openssl? Is it the size? libssl1.1 has
about 4MB. That can be a reason.
> future, no such requirement exists at the moment, and other parts of
> lighttpd link against libcrypto (not libssl). The lighttpd build
> would have to be modified if lighttpd were to provide some algorithms
> with the core (e.g. SHA1), rather than obtaining them from libcrypto,
> and then mod_openssl built separately. So for now, let's not do
> mod_openssl as a separate package.
Splitting will become easier once we have the Provides as consumers will
then know that they should Depends: lighttpd-mod-openssl. They won't
have to know whether that's a virtual or real package.
> As you proposed, we might proceed with creating lighttpd-modules-mysql
> and lighttpd-modules-ldap to start the transition, as that makes sense
> to group the modules depending on the database so that a future Debian
> release can remove those dependencies from the core.
I'd not have lighttpd depend on lighttpd-modules-ldap. Yes, that reduces
functionality and might break users' installations, but we can explain
that in NEWS. A transitional Recommends might be an option.
> I agree with your proposal for lighttpd-modules-mysql and
> lighttpd-modules-ldap, though I might suggest lighttpd-modules-mariadb
> instead of lighttpd-modules-mysql.
I called it mysql, because the modules have that in their name. Is
upstream going to rename the modules?
> I propose leaving the -dev build dependencies in debian/rules so that
> others could more easily build dpkgs of the additional modules, and
> install those modules themselves.
If people actually want those modules, then we should simply build and
package them now.
I sense that we'll be adding 7 new packages (ldap, mysql/mariadb,
openssl?, pgsql, dbi, pam, sasl) soon. Not nice for metadata, but at
least we gave it some thought.
Are more pgsql modules on the horizon? (e.g. mod_authn_pgsql? Should we
call the package lighttpd-mod-vhostdb-pgsql or lighttpd-modules-pgsql?)
Also same question for sasl and dbi.
Helmut
Reply to: