This is a bad packaging practice which happens way to often within all
the GTK/Gnome packaging (cloning for mutter as well).  The scenario goes
as follows:

  - upload a new package

  - build fails on "all", not building the "common" package.

  - build succeeds on other architectures, in most cases
    because the packagers don't run the tests, or ignore test
    results.

  - the packages then are not installable anymore until the
    uploads are in sync, blocking any other builds depending
    on these packages.  This can take a long, if the uploader
    goes to vacation, or a new package build takes ages (yes,
    LLVM had that issue as well, and LLVM builds take days).

proposed patch attached. Note that (>= ${source:Version}) has the same
problem, and doesn't help either. Feel free to use some other version
constraint than the upstream version.

diff -Nru folks-0.15.9/debian/control folks-0.15.9/debian/control
--- folks-0.15.9/debian/control	2024-03-23 12:41:20.000000000 +0100
+++ folks-0.15.9/debian/control	2024-03-24 22:06:08.000000000 +0100
@@ -31,7 +31,7 @@

  Package: libfolks26
  Architecture: any
-Depends: folks-common (= ${source:Version}),
+Depends: folks-common (>= ${upstream:Version}),
           ${misc:Depends},
           ${shlibs:Depends}
  Recommends: libfolks-eds26
diff -Nru folks-0.15.9/debian/rules folks-0.15.9/debian/rules
--- folks-0.15.9/debian/rules	2024-03-23 12:41:20.000000000 +0100
+++ folks-0.15.9/debian/rules	2024-03-24 22:06:08.000000000 +0100
@@ -35,3 +35,8 @@
  	dh_auto_test --no-parallel -- --timeout-multiplier 3

  override_dh_gnome_clean:
+
+
+override_dh_gencontrol:
+	dh_gencontrol -- \
+	  -Vupstream:Version=$(shell dpkg-parsechangelog -S Version | sed
's/-[^-]*$$//')

Cloning a bug in the way you did is not very helpful. mutter's
situation is different than folks.

The mutter binary package has Depends: mutter-common (>= ${source:Version})

That allows mutter to be binNMU'd.

An alternative is to do something like evolution which has this override:

dh_makeshlibs -V'libevolution (>= $(DEB_VERSION_UPSTREAM)),
libevolution (<< $(DEB_GNOME_NEXTVERSION))'

which translates to this when built on Unstable (3.50.3-1+b1) :

dh_makeshlibs -V'libevolution (>= 3.50.3), libevolution (<< 3.51)'

We do actually need the upstream version of the -common package to
match the other binary packages. I am not convinced there is even
value in switching to the evolution style since it seems rare for
there to be an upload after the first upload for an upstream version
(-2 or higher basically) where the fact that sometimes arch: all
builds slower than other architectures is enough of a problem in these
packages to make the packaging more complicated.

I would prefer to revert your Ubuntu diff for mutter so that if this
bug is fixed, it is fixed in Debian first.

Thank you,
Jeremy Bícha

that works for Debian, but not Ubuntu. A failing build on amd64 and
succeeding builds on the other architectures makes the packages
uninstallable on all other architectures.

then please fix it, allowing no-change uploads for Ubuntu as well.

Matthias

I misunderstood what you were proposing in part because the "patch"
you proposed here was not for mutter and the version you pushed into
Ubuntu had a hardcoded version instead. And I didn't read carefully
enough.

To move your idea forward, I proposed
https://salsa.debian.org/gnome-team/libshumate/-/merge_requests/4
which also is not mutter but I think is a simpler test case which we
can then apply to other packages including mutter if it is accepted.

Thank you,
Jeremy Bícha

libmutter now has
Depends: mutter-common (>= ${source:Upstream-Version})

which becomes
Depends: mutter-common (>= 51.0)

That satisfies your request for looser dependencies for NMUs etc., in
Debian and Ubuntu, while still ensuring that the mutter library is
installed with the minimum version of its gsettings schemas, etc.

I think this dependency syntax is useful, so I'll use it more often in
other packages. It is far less commonly used in Debian than the
previous syntax.

Thank you,
Jeremy Bícha