[ Note: I think this is of general interest, so I am cc-ing it to debian-devel. Please reply to the policy mailing list. ]
I've been experiencing considerable friction with Manoj on this list (debian-policy) for the past few months, and I finally realized today exactly where we differ. I'd like to take a step back from the current policy issues, and get a consensus on this issue, one way or the other, to clear it up so we can stop arguing it over and over under the guise of different proposals. The question is: What needs to be policy? Specifically, Manoj's point of view seems to be that as we develop programs that tie the system together and are used in many packages (examples are the menu system, update-alternatives, dpkg, etc), the interfaces these programs present eventually assume the weight of policy, and that those interfaces should be codified and included in the policy document. On the other hand, I think that these interfaces need not appear in policy. -------- Why do we have policy? We have policy to make the system consitent, and to give people a way to file bugs on a package that does not comply. With policy, we can file a bug saying that a package violates policy, even if that policy violation would not be seen as a bug in the world outside debian. For example, it is a policy violation for a package to contain a /usr/games/ directory with permissions 775 root.root [1], although doing so introduces no real bug. As another example, it is a policy violation for a package to install a menu file that places a menu item in Apps/WayCoolStuff/. These is no bug in the traditional sense of the word in such a package, but we say it has a bug because it violates policy. Again, we do this for consitency between packages. I believe that this is the only reason we need have policy. Now, we could add something to policy saying that dpkg-divert took options --add --remove and --list and spelling out exactly how it is to be used. Manoj indicated in a mail today that he is in favor of doing exactly that. I say we do not need to. If a script calls dpkg-divert --blart, the script that called it will die. This is a bug valid reason for filing a bug report, even if policy doesn't mention anything about this, and so there is no reason to encode this in policy. Conversely, if dpkg-divert stopped accepting --list, packages would fail, and bugs would again be filed, even if this was not covered by policy. Furthermore, I belive that there is no reason to encode things in policy that can not be solved by filing bug reports and modifying packages. For example, the Developers Reference gives rules for how long to wait before doing a NMU, and about which list you should announce an upload to. If a developer fails to follow those rules, we still cannot file a bug report, because no package is at fault (we can of course pester the developer to follow the rules). Even if the Developers Reference were part of policy, we still could not file a bug to correct these problems. Therefore, there is no reason for it to be policy. (And in fact, it isn't -- but it almost became policy once.) Now, I'm not arguing against documents like the Packaging Manual and the Developer's Reference. I'm just arguing that we gain no benefits from including them as part of policy. This is, I feel, an important issue, because in case you are not aware, the Packaging Manual has been a part of policy for a few months now. Take a look at the Packaging Manual sometime, read all 3 thousand lines or as much as you have time for, and see for yourself if there is anything to gain from making most of it policy. -- see shy jo [1] "The permissions on /var/lib/games are 755 root.root'." -- Policy
