what needs to be policy?
[ 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
Reply to: