Hi,
The confusion about whether the requirement is a "should" (normal) or "may"
(wishlist) can be simply fixed by delineating the section 7 as one that
specifies purely technical requirements, by using "can" in it. OTOH, the
section 2.4 provides rules that are to be followed to be a really
policy-compliant source package.
There was also needless duplication of content within the section 7, and use
of both "can" and "may". Additionally, the two sections weren't linked.
That's just bad documentation. :)
If there aren't any objections, I'm going to commit the attached patch to
the policy. It fixes the above problems without actually modifying the
meaning of the document in a way that requires more voting -- the rule is a
"should". Hopefully, it also alleviates the people's concern about packages
not having any build-dependencies, but not being build-essential-only, being
allowed to exist that way due to a "may" rule in the policy.
--
2. That which causes joy or happiness.
Attachment:
dif
Description: video/dv