XPost: linux.debian.policy   
   From: rra@debian.org   
      
   Bill Allombert  writes:   
   > On Tue, Feb 10, 2026 at 10:34:18AM -0800, Russ Allbery wrote:   
   >> Bill Allombert  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 (rra@debian.org)                 
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)