[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#30036: debian-policy could include emacs policy

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

Reply to: