On Mon, 28 Apr 2008 22:14:18 -0700, Russ Allbery <[EMAIL PROTECTED]> said:
> Policy is the only formal documentation we have right now of the
> control fields in a Debian package, so I think there's at least a
> prima facie argument for adding a specification for any new fields to
> Policy, at least unless that documentation is split off to some other
> source. I don't know of any other documentation that covers all the
> recognized control fields.
Even policy does not. Where is Vcs-Browser and
VCS-{Arch,Git,SVN,CVS} et al defined? Not in policy, for they do not
need to be: even though they are entered in directly by package
maintainers.
So the argument that no other documentation for dpkg exists is
not satisfactory, and it flies in the face of trying to fight policy
bloat: I would rather policy was a minimal document that only contained
things that a maintainer _had_ to know. Policy should be, err, policy,
and not merely documentation. If we lack documentation, the answer
should be to create the documentation, not to bloat policy. This
should be a bug against dpkg, really, if the behaviour of dpkg and
friends is not documented in detail.
As to the fact that other bits of Debian infrastructure had to
change, that is true. But that is not enough reason to put into policy
dpkg, dak, buildd, and other infrastructure documentation; we should
recognize that there are very many things that can create bugs; and
_any_ change in behavior of an infrastructure package can affect other
parts of the infrastructure, and change management practices should be
encouraged.
It is not as if writing current behavior into stone and
preventing any changes is a good thing for the project: the only reason
for writing an API down in policy is so that it does not ever change
(future versions of the package should adhere to the standard, and not
innovate: no one wants, for example, wild and wooly innovation from gcc
and libc -- and policy should, in my view, be close to a standards
document). If the behaviour is indeed subject to change, and is not a
standard API or behaviour that should be preserved by future dpkg
authors, then what we want is documentation, not policy.
manoj
--
It's a lot of fun being alive ... I wonder if my bed is made?!?
Manoj Srivastava <[EMAIL PROTECTED]> <http://www.golden-gryphon.com/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
