On Fri, May 10, 2002 at 11:25:33AM +1000, Anthony Towns wrote:
> > 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, assuming that this is correct behaviour, we have to use a SHOULD
NOT at this point, not a MUST NOT. Why would we argue with that?
> > 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.
As crude examples:
"A package name MUST consist of [list permissible characters] and
contain at least one letter. A package name MUST have at least two
characters in it."
"Filenames MUST be unique within a distribution, unless they are
handled using either Conflicts or dpkg-divert." (And there may well
be other ways out, but I can't think of them offhand. You get the
idea.)
"debian/rules MUST contain the following targets: .... debian/rules
MAY contain the following additional targets with meanings specified
below: .... debian/rules MAY contain other targets in addition to
these."
Julian
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London
website: http://www.maths.qmul.ac.uk/~jdg/
Debian GNU/Linux Developer, see: http://people.debian.org/~jdg/
Visit http://www.thehungersite.com/ to help feed the hungry
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
