Bug#1065816: weston: Dependency neatvnc found: NO found 0.8.0 but need: '< 0.8.0' ; matched: '>= 0.7.0'

[Simon McVittie <smcv@debian.org>]

Control: block 1036884 by -1

On Sun, 10 Mar 2024 at 10:37:51 +0100, Aurelien Jarno wrote:
> weston fails to build in unstable since the upload of neatvnc in version
> 8.0. From my build log on amd64:
...
> | Dependency neatvnc found: NO found 0.8.0 but need: '< 0.8.0' ; matched: '>= 0.7.0'

This is important for the 64-bit time_t transition, because weston is
part of that transition, and also because packages like gtk4 use weston in
headless mode to test their Wayland backends. This could be mitigated by
temporarily making gtk4 skip its Wayland tests on 32-bit architectures,
but with gtk4 hat on, I would not be comfortable with doing that in
the long term, because in practice it seems to be inevitable that
functionality that isn't tested doesn't actually work.

Looking at the recent neatvnc upload, I was surprised to see that its
former maintainer updated it to a new upstream release in the same upload
as orphaning it (#1065738), and also updated the closely-related wayvnc
package to a new upstream release that matches neatvnc.

I also noticed that neatvnc 0.8.0 has an ABI break without bumping the
SONAME (#1065824), although that might be ignorable since nothing in
Debian seems to use the affected symbol.

I think the options here in the short term are:

1. adapt weston to support neatvnc 0.8.0, if it's straightforward to do so;
2. revert neatvnc to 0.8.0+really0.7.1+dfsg and wayvnc to 0.8.0+really0.7.2,
   and revisit this later, when we are *not* in the middle of a transition
   that touches thousands of packages;
3. temporarily disable the VNC backend in weston, and revisit this later

I would personally be very tempted by (2.) since it seems like the option
with least risk of regressions when compared with what's currently in
trixie, but I have no particular knowledge of these packages, so it
would be better if the maintainers of weston and/or wayvnc could adopt
neatvnc and handle this in whatever way they prefer. If this situation
is not resolved then I might do the revert (2.), by QA-uploading neatvnc
and NMU'ing wayvnc.

Thanks,
    smcv