I'm not Paul, but I suspect he was looking at Policy §10.1: Two different packages must not install programs with differentfunctionality but with the same filenames. (The case of two programshaving the same functionality but different implementations ishandled via “alternatives” or the “Conflicts” mechanism [...].)implying that alternatives and Conflicts are the wrong tool if the two programs have different functionality (which an alternative to Meson and an alternative to Synaptic certainly do).
I'd really, really like to avoid renaming a binary that is meant to be executed via the command line.
Would alternatives really be that bad? What if the current /usr/bin/muon was moved to /usr/bin/muon-kde, muon-build was installed to /usr/bin/muon-build and /usr/bin/muon was shared between the two packages? What issues could it cause?
I don't think users really invoke KDE Muon via the terminal that often anyway, it is a Graphical APT frontend...
KDE Muon might be dead upstream (or not, today was the first time I was aware of it), but it's in Debian stable, testing and unstable as of today.Please talk to its maintainers, the Qt/KDE team, if you think Debian would be better without (KDE's) Muon than with it.
I don't think Debian would be better without KDE Muon, as far as I know its development may have ended but it still works fine :)
-- OpenPGP key: 66DE F152 8299 0C21 99EF A801 A8A1 28A8 AB1C EE49