-project Bcc'ed only.
On Thu, May 09, 2002 at 11:17:28PM +0100, Julian Gilbey wrote:
> On Fri, May 10, 2002 at 04:02:47AM +1000, Anthony Towns wrote:
> > On Mon, May 06, 2002 at 06:19:54PM +0100, Julian Gilbey wrote:
> > > > > Then each section could either have the structure:
> > > > > or we could merge them, and have policy dictates all in the form MUST,
> > > > > SHOULD, MAY, MUST NOT, etc., as in the RFCs.
> > > > I'm quite confident that trying to differentiate between requirements
> > > > and guidelines like this will turn out to be completely unhelpful and
> > > > a large waste of time, personally.
> > > Don't RFCs do this frequently? And I've never heard people making
> > > such a complaint about them.
> > RFCs have a different goal to -policy. RFCs specify things that get
> > implemented by different groups and have to be interoperable. -policy
> > doesn't.
> > There is only one "dpkg", [...]
> Who's talking about dpkg here?
Manoj, for one:
] [...] The policy group shall never propose additions to
] dpkg functionality, the way the section shalll be formulated. What
] shall be in the section is what the maintainers _must_ have in order
] for their packages to be built. This is the core interface that dpkg
] already presents [...]
> Policy covers far more than that.
Actually it covers different things than that, which is my whole point.
The RFC-style M/S/M remarks are just tangential.
> For
> example, when talking about shared and static libraries, there may be
> exceptional cases where both the shared library and the development
> parts (headers and static library) live in the same package. Then one
> would say something like "Source packages providing shared libraries
> SHOULD produce a binary package containing the shared library and
> another binary package containing the development files (headers and
> statically compiled library). The shared library MUST be compiled
> with the -fPIC option and the static library MUST NOT be compiled with
> this option. ..." (Please don't correct me on details here -- I
> haven't checked them up and that's not the point.)
Which is to say that if I demonstrate that your "MUST" or "MUST NOT"
could happen to have exceptions, that you're not going to listen, and
thus I've got no way of usefully demonstrating my point, which is that
almost every "MUST" you might choose will have some sort of exception,
and thus should be a SHOULD.
In the above, for example, the xlibs-pic package provides static libraries
that are compiled with -fPIC, making your MUST NOT inappropriate.
> So here, the "SHOULD" means that it must behave in this way unless
> there are exceptional circumstances, and the "MUST" means that there
> are no exceptions. I may be wrong in the details of this specific
> case, but this is the way I am thinking.
I completely understand the distinction you're trying to make, I just
think you'll find that there aren't many situations where "MUST" is
appropriate, and that there aren't any where it's particularly useful.
Cheers,
aj
--
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.
``BAM! Science triumphs again!''
-- http://www.angryflower.com/vegeta.gif
Attachment:
pgpbv5atV8hyl.pgp
Description: PGP signature