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

[Andrea Pappacoda]

Il giorno ven 19 ago 2022 alle 14:43:27 -07:00:00, Russ Allbery 
 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

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

[Russ Allbery]

Andrea Pappacoda  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 (r...@debian.org)  

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

[Vincent Bernat]

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.

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

[Andrea Pappacoda]

Il giorno ven 19 ago 2022 alle 18:51:31 +01:00:00, Simon McVittie 
 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

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

[Paul Gevers]

Hi,

On 19-08-2022 18:10, Luca Boccassi wrote:

On Fri, 19 Aug 2022 at 16:54, Paul Gevers  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?


Simon did that extremely well, as his suspicion was dead-on.

Paul


OpenPGP_signature
Description: OpenPGP digital signature

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

[Simon McVittie]

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

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

[Luca Boccassi]

On Fri, 19 Aug 2022 at 16:54, Paul Gevers  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

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

[Paul Gevers]

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.

Paul


OpenPGP_signature
Description: OpenPGP digital signature

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

[Luca Boccassi]

On Fri, 19 Aug 2022 at 15:48, Simon McVittie  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

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

[Simon McVittie]

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