Bug#1063605: debian-policy: mandate use of `dpkg-buildflags` for all software compilation on Debian

Russ Allbery [10/Feb  1:10pm -08] wrote:
> 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 agree with all this.

-- 
Sean Whitton

-----BEGIN PGP SIGNATURE-----

iQJNBAEBCgA3FiEEm5FwB64DDjbk/CSLaVt65L8GYkAFAmmNsN0ZHHNwd2hpdHRv
bkBzcHdoaXR0b24ubmFtZQAKCRBpW3rkvwZiQAKxEACLZfoJMVogDaZWSU5bRhBz
0+kOy541wsXAcHq5HTK4Jaochm1mD4Zq210+etmeylUeNHpUp8mI3ULgyJbRgM32
Ay1YuTA98f3iCLoXJ5d+Uuf+Ke5jVOiuGLfaYuBFEJQk772Eb9bkDc2DJ/hWIhyn
sZjyClF5t63tf2uCD9dc+ozaIciSW6/WsSwBNIXZQYnIFrKG0c+Kt77fnsdrgHKS
huDtMejJXMyGCIRa8MYSyeWGk5uqLH4/ae7k72db5fmbAsQ4F3HSRMSmv0gHS1to
FwwOaj31Bhx9RjdSzqKcqkAnUMI2vws1zSUrOR1W2M2WaFCnxkmgZ16uMXuzPNUS
ryW7sxUK7d6y+JYmYFoSuvGWkDKl+OQQBGTGw79jGA5tmoJCr8GxKAGixNBiQTE1
usXTgL6XcsyYPpbOjbBR2YbtsDa9ZwxwJDPw3QlHhyvZc1Mu1TP8NJxuf7rUPxfB
kPiDIxdTbzFcFRNapF/7briSV1EivoLdm7Qp7ljl5qOYxm25bgfJ5rGzg5QFYOZO
PPHgQgfa5k0ZpAenqIBFLBfzs/6e7lVPiqJF4uPCUP+8lqZ1OXxFeRrNwZJ8ZAyv
h/5YiWuQu2OdCGl1Mr/n5iNSTPMPhdxecVrjBFMExw8MBF0qkahkbV+ZeIikc5Cy
AbMbmBkYIazQjlOY3aNJKA==
=Qigq
-----END PGP SIGNATURE-----