How to avoid listen-port conflicts on package installation

I'm working on a private Debian package that deploys a service which binds to port 80.

[Service]
ExecStart=/usr/bin/foo --port 80

I realize almost every other package which serves HTTP is also going to try to bind to port 80. apache2.service for example, comes with this site enabled by default:

# /etc/apache2/sites-enabled/000-default.conf

    ...

Options: 1. Let the programs race for the bind(). Fastest wins 2. Add Before=apache2.service to foo.service 3. Add Conflicts=apache2 to debian/control With files, we often use update-alternatives to let packages negotiate (or users configure) what package gets to supply a specific file, but do we have anything similar for ports? ---- If I have apache2 installed and bound to port 80, then apt install nginx, I get:

$ sudo apt install nginx-light
...
Setting up nginx-common (1.18.0-6.1+deb11u3) ...
Created symlink /etc/systemd/system/multi-user.target.wants/nginx.service → /lib/systemd/system/nginx.service.
Job for nginx.service failed because the control process exited with error code.
See "systemctl status nginx.service" and "journalctl -xeu nginx.service" for details.
Setting up nginx-light (1.18.0-6.1+deb11u3) ...
Not attempting to start NGINX, port 80 is already in use.

So perhaps the solution is to enabling a service conditionally based on whether the port is already bound during installation (though nginx is now enabled, so I presume apache2 and nginx will race on next boot).