1. Forum
  2. Usenet
  3. LINUX.DEBIAN.DEVEL

  • Re: Bug#1017716: ITP: muon-meson -- Meson-compatible build system

    From Simon McVittie@21:1/5 to Andrea Pappacoda on Fri Aug 19 16:50:01 2022
    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)
  • From Luca Boccassi@21:1/5 to Simon McVittie on Fri Aug 19 17:50:01 2022
    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)
  • From Paul Gevers@21:1/5 to Debian Development on Fri Aug 19 18:00:02 2022
    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)
  • From Luca Boccassi@21:1/5 to Paul Gevers on Fri Aug 19 18:20:02 2022
    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)
  • From Simon McVittie@21:1/5 to Andrea Pappacoda on Fri Aug 19 20:00:01 2022
    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)
  • From Paul Gevers@21:1/5 to Debian Development on Fri Aug 19 21:20:01 2022
    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)
  • From Andrea Pappacoda@21:1/5 to All on Fri Aug 19 23:20:01 2022
    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)
  • From Vincent Bernat@21:1/5 to Andrea Pappacoda on Fri Aug 19 23:50:01 2022
    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)
  • From Russ Allbery@21:1/5 to Andrea Pappacoda on Fri Aug 19 23:50:01 2022
    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)
  • From Andrea Pappacoda@21:1/5 to All on Sun Aug 21 18:30:01 2022
    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)