[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: