> 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
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2071468

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

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


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to