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
signature.asc
Description: PGP signature
