Who to contact about removing package from upcoming 11 release?
tl;dr: I am looking for information on who to contact to make the case
for removing a package from the upcoming Debian 11 distribution. The
package maintainers do not answer emails. The package itself has
numerous bugs that make it unusable. Some of them date to 2015. When
the maintainers are unresponsive, I'm not sure the escalation process.
Full details:
postfixadmin is a php web application that is a front-end for a
postfix-based virtual domain email system. The postfixadmin package is
a Debianized installation of it, a la wordpress/phpmyadmin/etc, where
the upstream single-directory web application install is split into
Debian's customary /etc, and /usr/share
Testing's postfixadmin package has three bugs which preclude it from
working after installation:
- #857791 postfixadmin & dbconfig-common: mysql/mysqli mismatch (since
Debian 8)
- #926253 /usr/share/postfixadmin/lib/../templates_c does not exist on
new installation (Since Debian 9)
- #965075/#987998 wrong alias in postfixadmin conf-available for
apache2/lighttpd (Since Debian 9)
#965075 has been corrected in unstable, but the fix only covered
apache's configuration, and not lighttpd's. Why the maintainer didn't
fix it for both at once is beyond me, but I have now submitted #987998.
These are all relatively easy to fix, but have been in the package for
years, rendering it unusable without the fixes. If one has to fix
installation errors to get a Debian packaged web application to work,
the easiest solution is not to use the package at all and get upstream.
It is telling that of the dozen or so howtos for using postfixadmin in
Debian, exactly none that I can find suggest using Debian's package.
The concern I have with this remaining in testing and then Debian 11 is
primarily #926253. Since about 2018, upstream's postfixadmin has
required a writeable tmp directory called templates_c. This is not
created by the installer and the application fails without it. The
easiest solution and path of least resistance for users will be to
create the directory in /usr/share/postfixadmin with the rest of where
postfixadmin is installed. The Debian-appropriate location for this
should be /var/lib/postfixadmin/templates_c. I am concerned that should
users install and manually fix the package, that their fix will
interfere with proper fixes of the bug which will be disted after.
The maintainer clearly has been updating the package with upstream
changes and releasing it without testing. #965075/#987998 reflect
upstream's change of location for where they place the UI interface
directory. This upstream change occured in 2018. From upstream's
changelog:
Version 3.2 - 2018/05/02
- move public facing stuff into public/, this allows us to stop
exposing templates_c/ etc. to the world (but also means you'll need to
adjust your webserver config)
No version of the postfixadmin package released since then could have
been even tested by the maintainer before release (this includes
packages released for Buster & Bullseye)
If #857791, #926253, and #965075/#987998 cannot be fixed in testing then
my recommendation is to remove postfixadmin from testing, and leave it
unstable.
Reply to: