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.