Ben Armstrong wrote: > In case you haven't guessed by now, I'm doing a complete read of > Policy front to back, something which in all these years of being > with Debian I have never done. I'm wondering how many other DDs > are in the same position. I will certainly personally recommend it > to all DDs or applicants I work closely with. I must say it is > quite a lot more interesting a read than I thought it would be, and > for the most part, not difficult.
Yes, it's a good read. I guess I haven't read it straight through in 5 years or more, probably should again. > My eyes did glaze over for a bit on chapter 6. In particular, > section 6.4 sent me reeling. I think it could be supplemented with > some specific examples. That summary, and the following sections > 6.5 through 6.7, do very little to help me understand what is > happening behind the scenes. I think those sections don't read > well because it is not entirely clear to someone not familiar with > dpkg what all the italicized metasyntactic elements represent. The reason that's so dense and different in tone is that it was imported from the old packaging manual, which was dense and opaque throughout. I still don't think it belongs in policy. Section 6.4 is an excellent reference section if you already know how everything (currently) works, but aside from the fact that scripts must behave sanely with all of the arguments assigned to them in that section, there is no real policy requirement here. > I think it is a shame that this chapter is so dense. I got the sense > that herein lies one of the most brilliant, robust parts of the > Debian packaging system. Yet in the end, I had only a very sketchy > understanding of how it fit together. Is there anything that can be > done to make it clearer for the uninitiated without needlessly > bloating Policy? We could relegate it to an appendix or footnote, and replace those sections with ones that explain in detail what each of the maintainer scripts are for, what arguments they are usually called with, emphasize that, for example, a postinst is *not* just called when you're installing/upgrading a package (so test $1 before doing anything), and point to the appendix for other, rarely used arguments and ways the scripts may be called. -- see shy jo
