[Debian GNUstep maintainers] Bug#1112161: gnustep-base: Problematic dependency/usage on dpkg-dev

[Yavor Doganov]

Control: tags -1 + confirmed pending

Hi!

On Wed, 27 Aug 2025 04:19:35 +0300,
Guillem Jover wrote:
> X-Debbugs-Cc: debian-cross at lists.debian.org

I kept that in CC.

> The libgnustep-base1.31 binary package has a run-time dependency on
> dpkg-dev, because its shared library has been patched to use
> dpkg-architecture to fetch the DEB_HOST_MULTIARCH variable.

Right.

> Given that this is shared library package, the run-time dependency on
> dpkg-dev ends up pulling the entire build-essential, and I think the
> current reason for the dependency is problematic in any case.

I agree this is a problem and I've always felt the solution that I've
chosen back then is not entirely correct.

> The patch with those changes is supposedly to support the multiarch
> layout and cross building, but it's not clear whether the cross
> building changes could be restricted to the cross.config file,

Yes, changes for cross bulding are in cross.config plus few tiny
changes in configure.ac (hard-coded pkg-config and an override for
sparc64 due to alignment requirement).

> and the changes to the Objective C file could be done by hardcoding
> the value computed at configure time?

Thanks, that's way better and I wonder why such an obvious thing
hasn't crossed my mind.  It simplifies the patch a lot and avoids the
performance penalty of spawning dpkg-architecture (plus the benefit of
avoiding the dpkg-dev dependency).

> Otherwise the shared library might potentially end up returning the
> wrong pathname not matching its own architecture (because
> dpkg-architecture will honor the already set environment variables).

That's already the case -- the current version of the patch checks if
the variable is set in the environment (so dpkg-architecture is not
involved here):

$ dpkg --print-architecture
amd64
$ dpkg --print-foreign-architectures
i386
x32
$ AClock
(program starts successfully)
$ DEB_HOST_MULTIARCH=armhf-linux-gnu AClock
2025-09-07 19:25:06.059 AClock[2583241:2583241] Did not find correct version of backend (libgnustep-back-032.bundle), falling back to std (libgnustep-back.bundle).
2025-09-07 19:25:06.059 AClock[2583241:2583241] NSApplication.m:306  Assertion failed in initialize_gnustep_backend.  Unable to find backend back
AClock: Uncaught exception NSInternalInconsistencyException, reason: NSApplication.m:306  Assertion failed in initialize_gnustep_backend.  Unable to find backend back

The new version of the patch (not yet pushed) will ignore it and use
only the hard-coded value determined at configure time.

> I just noticed this on a recently upgraded system (to Debian trixie),
> which has otherwise no use for development files, and where
> build-essential got pulled in.

Many thanks for the report, will upload after some testing.