Bill Allombert <[email protected]> writes: > On Tue, Feb 10, 2026 at 10:34:18AM -0800, Russ Allbery wrote: >> Bill Allombert <[email protected]> writes:
>>> But then tracking Debian policy is sufficient (and mandatory already), >>> so tracking dpkg-buildflags is not needed. >> Hm, am I missing something? I don't see any mention of, e.g., >> -ffile-prefix-map in Debian Policy. So far as I know, that is tracked >> primarily in dpkg-buildflags. > Reproducible build is required by policy, while -ffile-prefix-map is a > mean to that end, not a goal in itself. > We could update Debian policy to mandate the effect provided by > -ffile-prefix-map (reproducible filename in log) more precisely than > just mandating reproducible build (which is not well-specified in Debian > policy). Sure, I agree, we in theory could do that. In practice, I suspect we won't, though, even if we intend to do so. I see this as part of a long trend in Policy maintenance. Originally, in part due to its origins in a world that had far fewer tools, Debian Policy (by way of the Packaging Manual) was a fairly comprehensive guide to everything that went into creating a Debian package from the ground up. With only that one document, in theory you could work out how to create a valid Debian package from first principles and common UNIX tools. Over time, it has stopped being that, for a variety of reasons. One major reason is that the tools have both become much better and more universal, and the underlying tools have their own documentation. Spending Policy maintenance time exhaustively documenting precisely what dpkg-buildpackage does under the hood has therefore been less and less appealing because the audience for such documentation is tiny and dpkg is already maintaining largely parallel documentation. People therefore stopped working on it, that documentation in Policy in some cases fell out of date, and it has only been fitfully updated. The same has been true for new requirements. If there is a tool that already does what Policy wants to happen, we have increasingly been documenting use of the tool rather than describing in detail precisely what the tool does. This is a tradeoff, since it does make it harder to write new tools, but I think it's a realistic tradeoff given that we are not suffering from idle hands or an excess of resources. In a world in which Policy is not keeping up with very long-standing changes (triggers, multiarch) that we have not found the time to document properly and which *are* packager-facing and cannot be easily addressed by using a standard tool, and have also not been keeping up with the regular requests for changes, I'm looking for more places where Policy can specify the high-level desired state and delegate the details to a standard tool. This lets us focus Policy maintenance on the places where we provide the most benefit (telling packagers about things they need to pay direct attention to) and not spending time documenting the internal behavior of tools that by and large one can simply use. That general desire does not imply that any specific example of a tool will fall on one side or the other of a line. For example, I am still reluctant to remove from Policy all the things that debhelper handles automatically; I think it's healthy for Policy to be an (incomplete, necessarily, due to lack of resources) specification that debhelper implements. But the dpkg suite is one of the primary examples of a set of tools to which we delegate a lot of details without exhaustively documenting them, in large part because dpkg maintains its own exhaustive documentation. I'm not sure if I understand the primary source of your objection. If the primary issue is that you would prefer Policy to be comprehensive and not delegate the details to tools, well, I understand that and I can see a lot of ways in which that would be ideal, but I don't think it's realistic. If the objection is to having to sync with dpkg-buildflags specifically because it's another place you have to look besides Policy, I'm not sure that's really that bad? For the packages that can't just use dpkg-buildflags directly for whatever reason, you can just occasionally run dpkg-buildflags from the top level of your Debian packaging tree and eyeball the relevant flags and see if there's anything new you don't recognize. I would expect this to take at most a minute or two for packages where the maintainer is already so deeply familiar with the workings of the compiler that they're doing custom flag management. I really do not want to have to push through a Policy change every time we discover a new compiler flag that is helpful for, e.g., reproducible builds. I would rather let other people handle that in a division of labor and focus on places where Policy is adding unique value. Also, just on a practical sense, I don't think we *will* handle such updates in a timely fashion, just based on historic evidence, although of course I always aspire to do better. I completely agree that it would be a mistake for Policy to say that one *must* use dpkg-buildflags or sync to its output, but I do think *should* is the appropriate level and the appropriate practical compromise here. -- Russ Allbery ([email protected]) <https://www.eyrie.org/~eagle/>
