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.

smcv

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 19 Aug 2022 at 15:48, Simon McVittie <smcv@debian.org> wrote:

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.

And if KDE Muon is indeed dead, simply having a "Conflicts: muon" and
using the same path should be ok as well?

Kind regards,
Luca Boccassi

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------lz4QoS4brF6y1QJ0xSTfzaFm
Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64

T24gMTktMDgtMjAyMiAxNzo0MSwgTHVjYSBCb2NjYXNzaSB3cm90ZToNCj4gQW5kIGlmIEtE RSBNdW9uIGlzIGluZGVlZCBkZWFkLCBzaW1wbHkgaGF2aW5nIGEgIkNvbmZsaWN0czogbXVv biIgYW5kDQo+IHVzaW5nIHRoZSBzYW1lIHBhdGggc2hvdWxkIGJlIG9rIGFzIHdlbGw/DQoN Ck5vLg0KDQpQYXVsDQo=

--------------lz4QoS4brF6y1QJ0xSTfzaFm--

-----BEGIN PGP SIGNATURE-----

wsB5BAABCAAjFiEEWLZtSHNr6TsFLeZynFyZ6wW9dQoFAmL/shwFAwAAAAAACgkQnFyZ6wW9dQqD dgf+NKDJV0LnBo8YPE41HrHP6pVPmqaFSRHs/201yoEUJusIhY7h7R+uXnZEz7nfsLAFjncWquB2 vG+Mk2RsqMbhiNC7+j7prQRpNdgOGR0Sdo7pGIVMmLXxI5nT+l8oSwwOvAuJKAtwySDhI7Z6nnsz WrTavkwHsHdTv58COKuRGde0q73zeTblRiMd64WKJvEC3mF5mkSz0ktz27nNyV7OZZelFoqlmJSQ KmUUYJ4TYZADgbR1+PcaB53Balvn15aRrQ8u/BcfJVfrowwYBHH9RB84h/wVad7AKjo69scLc2QE pN+eQpOnPNOqPdI9efIvcg6zDTYWtKqPGa56j0RsSA==
=z5iu
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 19 Aug 2022 at 16:54, Paul Gevers <elbrus@debian.org> wrote:

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.

Care to elaborate a little?

Kind regards,
Luca Boccassi

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 19 Aug 2022 at 19:19:25 +0200, Andrea Pappacoda wrote:

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.

I'm not aware of a specific rule for how long a package or executable
name needs to be not-in-Debian before that name can be reused, but from a least-astonishment point of view, it would seem reasonable to me to want
to have at least one stable release that didn't include /usr/bin/muon
before recycling that name in PATH for Meson-compatible muon.

smcv

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------JOYId24hOTCOD2zqDjE0HTmJ
Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64

SGksDQoNCk9uIDE5LTA4LTIwMjIgMTg6MTAsIEx1Y2EgQm9jY2Fzc2kgd3JvdGU6DQo+IE9u IEZyaSwgMTkgQXVnIDIwMjIgYXQgMTY6NTQsIFBhdWwgR2V2ZXJzIDxlbGJydXNAZGViaWFu Lm9yZz4gd3JvdGU6DQo+Pg0KPj4gT24gMTktMDgtMjAyMiAxNzo0MSwgTHVjYSBCb2NjYXNz aSB3cm90ZToNCj4+PiBBbmQgaWYgS0RFIE11b24gaXMgaW5kZWVkIGRlYWQsIHNpbXBseSBo YXZpbmcgYSAiQ29uZmxpY3RzOiBtdW9uIiBhbmQNCj4+PiB1c2luZyB0aGUgc2FtZSBwYXRo IHNob3VsZCBiZSBvayBhcyB3ZWxsPw0KPj4NCj4+IE5vLg0KPiANCj4gQ2FyZSB0byBlbGFi b3JhdGUgYSBsaXR0bGU/DQoNClNpbW9uIGRpZCB0aGF0IGV4dHJlbWVseSB3ZWxsLCBhcyBo aXMgc3VzcGljaW9uIHdhcyBkZWFkLW9uLg0KDQpQYXVsDQo=

--------------JOYId24hOTCOD2zqDjE0HTmJ--

-----BEGIN PGP SIGNATURE-----

wsB5BAABCAAjFiEEWLZtSHNr6TsFLeZynFyZ6wW9dQoFAmL/4a0FAwAAAAAACgkQnFyZ6wW9dQo7 Ewf+I/vmLvGeiBsqkz168nBw5iR1I0q+H9yMtOjnuD+T3mQICcSZ9xjwp/yWSAb1jS9PJRfz2wGX qvaE+LTt7h+ggPG+D4SyYJwYoK4kElaf9vRUnS5REwVyVTlW95Siw6dp/a9hYI+aK8uvWhdN0z94 CVKNJ7OEYBX0+hk4KGWitBsqBky/3BPsBCFJPRt7yDmn9u0ci+B37LhZ1og7R8BRvd3WkQ3ys/Bv 3rtfwaZZ1FKXfjgg/N/mfpBWMt0YsutHZ9XbVGvchQRJjV878FeE0PiQmXMcpL76eS22Hdi0dj6b UUpuTiYOR3Z6Cf8wV9lVUyeTNXoMr/Gdyl+X7Ig+qQ==
=XkI8
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Il giorno ven 19 ago 2022 alle 18:51:31 +01:00:00, Simon McVittie <smcv@debian.org> ha scritto:

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).

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2022-08-19 23:14, Andrea Pappacoda wrote:

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...

I think your best bet is to ask KDE maintainers if they can rename the executable on their side. As it is likely started from a .desktop, they
may not mind that.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Andrea Pappacoda <andrea@pappacoda.it> writes:

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.

(It's bad enough when it happens between releases, although in that case sometimes we live with it as the least bad option.)

[1] https://www.debian.org/doc/debian-policy/ch-files.html#binaries

--
Russ Allbery (rra@debian.org) <https://www.eyrie.org/~eagle/>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Il giorno ven 19 ago 2022 alle 14:43:27 -07:00:00, Russ Allbery <rra@debian.org> ha scritto:

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.

Thanks, thinking about this a bit more made me realize that yeah, it's
better not to do this.

As mentioned by Vincent, I'll try asking the Qt/KDE team about this
conflict.

Thank you all for the feedback!

--
OpenPGP key: 66DE F152 8299 0C21 99EF A801 A8A1 28A8 AB1C EE49

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)