The upstream name is "muon", but this package and /usr/bin/ name is already used by KDE Muon, a [dead] synaptic alternative.
I'm not sure how to handle this conflict; naming the Debian package "muon- meson" or "muon-build" seems fine, but renaming the "muon" binary might be less
desirable.
On Fri, 19 Aug 2022 at 13:57:50 +0200, Andrea Pappacoda wrote:
The upstream name is "muon", but this package and /usr/bin/ name is already used by KDE Muon, a [dead] synaptic alternative.
I'm not sure how to handle this conflict; naming the Debian package "muon- meson" or "muon-build" seems fine, but renaming the "muon" binary might be less
desirable.
muon-build seems more consistent with its own domain name muon.build, the reference meson implementation's domain name mesonbuild.com, and their
shared dependency ninja being packaged as ninja-build.
On 19-08-2022 17:41, Luca Boccassi wrote:
And if KDE Muon is indeed dead, simply having a "Conflicts: muon" and
using the same path should be ok as well?
No.
And if KDE Muon is indeed dead, simply having a "Conflicts: muon" and
using the same path should be ok as well?
I had the same idea, even if it is not extremely elegant. But Paul doesn't seem to agree; why?
I'm not Paul, but I suspect he was looking at Policy 10.1:
Two different packages must not install programs with different
functionality but with the same filenames. (The case of two
programs
having the same functionality but different implementations is
handled 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).
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.
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...
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?
Debian specifically disallows providing the same binary path from
multiple
packages in cases where the two binaries do not do the same thing with roughly the same arguments [1]. It would create a situation where /usr/bin/muon on different Debian systems can do wildly different
things
depending on what packages are installed or even on what order in
which
they're installed. That in turn creates user confusion, can cause
weird
problems, etc. It's just too surprising for users for the same
binary to
be entirely different things on different Debian systems with the same
major release installed.
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 339 |
Nodes: | 16 (2 / 14) |
Uptime: | 00:08:15 |
Calls: | 7,466 |
Calls today: | 2 |
Files: | 12,691 |
Messages: | 5,627,862 |