ISPConfig_update.sh detects mailman as installed when it is mailman3

Hello,

I use Debian Bullseye and have migrated my lists from mailman2 to mailman3 successfully, managing lists out of ISPConfig is OK for users.
After removing all lists from the ISPConfig3 interface, I have purged mailman package, removed /etc/mailman and /var/lib/mailman.

Then I thought to remove Mailman management from ISPConfig3 by running ispconfig_update.sh --force
But the line "Configuring mailman" is still displayed and ISPConfig placed its mailman related configuration files in /var/lib/mailman.
It should not have bad impacts, except placing useless config files. But I would have preferred having nothing about mailman as mailman3 is not managed by ISPConfig. And I still have the ability to configure mailing lists in the ISPConfig3 interface.

By reading the source code of ISPConfig, in the file install/lib/installer_base.lib.php at line 213 there is the following:

Code:

		if(is_installed('mailman') || is_installed('mmsitepass')) $conf['mailman']['installed'] = true;

Which looks to be the cause of this confusion except if there is something I missed.
Checking for mailman looks strange for Debian, because I don't remind about a mailman command in mailman2, but it is the command line for mailman3.
Is it the case in other supported distro?

Why checking something else than mmsitepass for mailman?
Couldn't checking for something else E.G. rmlist be equally liable to check for mailman2 to avoid something used by mailman3?

And what could I do to avoid Mailman to be reconfigured and displayed in the interface after ISPConfig update?

 

Mails are working as before, also for domains used in Mailman3.
I posted a diff in the issue about mailman3 support on the ISPConfig gitlab which is working for me.
Websites are not impacted because I use a dedicated virtual host for MM3 web, in fact the only ISPConfig3 configuration I changed is the Postfix configuration to replace mailman2 config by Mailman3 where applicable and added a conf-custom file with these modifications.

Mailing list are asked in my case, staying on Bullseye with packages ported from Buster to have an unmaintained software looks worse than looking for an alternative tool IMHO.