Manoj Srivastava wrote: > I disagree. If a document is indeed carrying the weight of > policy, I would like to see it in one place, rather than having to > install a gazillion packages and hunting for the document in > question. > > b) The sub policy documents should not be at the whim of any one > person for an indefinite interval. After they stabilize, and hence > do not need immediate and continuous rewrites from the author(s), > the sub documents should be brought under the democratic control > as exercised by this mailing list. > c) Putting the document under this mailing list shall ensure that no > part of Debian policy is again subject to the whims of any > individual (no matter how exemplary that person may be).
I just thought I should mention the menu package and the menu subpolicy, which is currently not in the policy manual, just referred to by section 3.6. It's stable, and it has been for about a year now. According to what you're saying, /usr/doc/menu/menu.sgml should be subsumed into policy. I happen to disagree, in the specific case of the menu package, just because the level of detail that menu.sgml goes into is not necessary for the policy manual. Maybe we could pull some parts of it out, like the menu hierarchy and icon requirements and put them in the po0licy manual proper. Other parts, like the specifics of exactly what the postinst and postrm scripts should do, how the menu-methods files are formatted, how the menu files themselves are formatted, how the user can override menu files, etc, have no place in policy. Another reason to keep a lot of this highly detailed technical stuff out of policy is because if it were made policy, Joost would have his hands tied to make large changes to the design of the menu package - such changes would probably violate policy! Another example is the FSSTND - including this in policy would double the size of policy with lots of details, so we don't, we just refer to the actual document. We don't seem to be worrying here about the FSSTND people making whimsical changes to the document (some might argue that they have done so and that's called the FHS ;-), since if they do we can take action (like making exceptions about keeping /var/lib/dpkg/ where it is even though the FHS wants it moved). I just skimmed the emacsen policy. If anything, it has more techical detail than does the menu package's documentation. Far more detail, in far more length (200 lines) than what's found in the policy manual today for comparably complicated subjects. For example, the policy devotes only a few pages to describing what should be done with maintainer scripts - only briefly touching on the huge amount of complexity there, and barely mentioning things like update-alternatives and dpkg-divert. Heck, we even reference the POSIX standard in the policy manual by requiring #!/bin/sh scripts use only POSIX features. We *can't* subsume POSIX into policy, due to copyright. -- see shy jo
