Comment 3 for bug 2071468

> 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.