[Bug 2071468] Re: ELF package metadata failure: environment variable ‘DEB_HOST_ARCH’ not defined

[Luca Boccassi]

> just curious: are there any pointers to these discussions? It seems
odd to design a format that has quoting issues from the beginning.

Unfortunately I don't have links, it's across various maling lists and
bug trackers from 2/3 years ago or so.

> I don't like having a 99% solution, and skip stuff otherwise.

Every dpkg feature/flag is a 99% solution. Hardening, frame pointers,
reproducibility, none of these feature flags have 100% usage across the
entire package base - and that's normal, because there's always a 1% of
packages doing really, really weird stuff, and it's just not worth the
effort. This already approaches max utility with a 99% coverage, there
is very very little to be gained to go out of our way to cover the
remaining 1%.

>  - a package build creates a build specific spec without relying on
any environment variables. That would be a change in dpkg, plus passing
the --package-metadata in the build flags.

That gets messy because you have to create the file and manage it and
delete it, at exactly the right time, and again against packages that
will do extremely weird things to any location that you might pick to
write it out to. Pick any directory in the build tree or outside it, and
there will be at least one package rm -rf'ing it at the wrong time. We
tried this first in Fedora, and then quickly moved away from it, as it
was just too difficult and much more prone to failure.

>  - the gcc and clang drivers insert the --package-metadata option on
it's own, if it is not present, and if all the env vars are present.

This requires again changing all the linkers, and it is extremely
unlikely that such changes will be accepted, so you'll have to carry out
of tree patches forever for bfd, gold, lld and mold.

If you want to change the linkers, it seems to me it would be much more
likely to be able to land a patch that changes the spec file's getenv()
to take a default fallback value in case the env var doesn't exist, or
something along those lines. Then it would just set the value to an
empty string when missing, and that will be enough to stop the build
failures.

Alternatively, originally the change did not use dpkg-buildflags to add
to ldflags. It could be changed again to avoid that, if the problem is
weird packages using dpkg-buildflags manually and only picking some bits
from it. I could go back to being set via DEB_LDFLAGS_MAINT_APPEND for
example.

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to dpkg in Ubuntu.
https://bugs.launchpad.net/bugs/2071468

Title:
  ELF package metadata failure: environment variable ‘DEB_HOST_ARCH’ not
  defined

Status in dpkg package in Ubuntu:
  New

Bug description:
  The ELF package note metadata introduced in dpkg 1.22.6ubuntu11
  (refined in 1.22.6ubuntu14) can cause this failure:

  ```
  gcc fatal error: environment variable ‘DEB_HOST_ARCH’ not defined
  ```

  This happens when the `-specs=/usr/share/dpkg/elf-package-
  metadata.specs` parameter is set but the needed environment variables
  are not set. Cases:

  1. Only the LDFLAGS is queried from dpkg-buildflags. Affected source
  packages builds: python3.12, openjdk-21, cdbs (causing dvbstreamer and
  rp-pppoe fail to build)

  2. autopkgtests

  This approach is too fragile. An alternative approach would be to specify the `--package-metadata` linker flag directly. The problem with that approach is that the curly brackets and quotation marks need to be escaped. Example failure: Building dpkg would add this parameter to the LDFLAGS:
  ```
  -Wl,--package-metadata,{"type":"deb","os":"ubuntu","name":"dpkg","version":"1.22.6ubuntu15","architecture":"amd64"}
  ```
  The following configure script call (non-relevant parameters deleted):
  ```
  $ gcc -Wl,--package-metadata,{type:deb,os:ubuntu,name:dpkg,version:1.22.6ubuntu15,architecture:amd64}
  /usr/bin/ld: cannot find {type:deb: No such file or directory
  /usr/bin/ld: cannot find os:ubuntu: No such file or directory
  /usr/bin/ld: cannot find name:dpkg: No such file or directory
  /usr/bin/ld: cannot find version:1.22.6ubuntu15: No such file or directory
  /usr/bin/ld: cannot find architecture:amd64}: No such file or directory
  ```

  Proposed solution: Add support for an `--escaped-package-metadata` parameter to the linkers that takes an URL encoded (RFC 3986) parameter. Example:
  ```
  -Wl,--encoded-package-metadata,%7B%22type%22:%22deb%22%2C%22os%22:%22ubuntu%22%2C%22name%22:%22dpkg%22%2C%22version%22:%221.22.6ubuntu15%22%2C%22architecture%22:%22amd64%22%7D
  ```

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dpkg/+bug/2071468/+subscriptions