David Kalnischkies writes ("Re: Bug#882445: Proposed change of offensive
packages to -offensive"):
> On Wed, Nov 22, 2017 at 05:18:37PM -0700, Sean Whitton wrote:
> > > "cowsay-offensive". In this situation the "-offensive" package can
> > > be Suggested by the core package(s), but should not be Recommended
> > > or Depended on, so that it is not installed by default.
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> While it seems to be a reasonable explanation for why it should be at most
> a suggests, this half-sentence is hardcoding behaviour of a specific
> package manager in its current default configuration into policy.
That's why I said, informally, "should".
> Personally, I would vote for just dropping the half sentence as the use of
> Suggests follows directly from its definition – as the whole point of a
> maintainer introducing an -offensive package is very likely that it is
> "perfectly reasonable" to not install it: Why introducing it otherwise?
I'm not wedded to this second half of the sentence.
> > I second this patch. I suggest we add it as section 3.1.1, i.e., as a
> > subsection to 3.1 "The package name".
>
> [As this is the first subsection I wonder if there will soon be many
> more "rip-off" naming conventions added like python-*, *-perl, … and if
> for style reasons its a good idea to have -offensive be the first]
Aren't these conventions in the python policy, perl policy, etc. ?
Geert Stappers writes ("Re: Bug#882445: possible offensive packages in
suggest"):
> Those are two things:
> - the name
> - the depends
>
> Don't bother on the name.
> Allow "-dark" "-funny" "-religion" and other suffixes.
I'm not sure I follow whether you mean "please do not specify the name
at all" or "I do not mind what you specify". I definitely want to
specify that "-offensive" should be used rather than (say) "-off".
It is true that "offensive" may not always be a good characterisation
of the nature of the issues. That is why I said "usually".
> Be strict on the dependencies. Proper use of
> - must
> - can
> - should
> - may
> as in
>
> } In this situation the "-suffix" package must be Suggested by the core
> } package(s), but may not be Recommended or Depended on, so that it is
> } not installed by default.
I deliberately used "should". Whether to split things out at all is a
matter for the maintainer's judgement. It would be silly to say to
the maintainer "you may decide to split things out, but if you do, you
must not use Recommends". I can imagine hypothetical situations where
Recommends would be appropriate.
That is, there is a spectrum:
less problematic content
just A containing all content right in some cases
A -Depends-> A-offensive very probably silly
A -Recommends-> A-offensive right in unusual cases
A -Suggests-> A-offensive right in some cases
A (no dependency) A-offensive right in some cases
just A, but censored right in some cases
package not in Debian at all right in some cases
more problematic content
We don't need policy to explain why Depends is probably daft here.
The maintainer will figure that out. The bug I mentioned earlier
shows that it is a good idea to explicitly deprecate Recommends. I
doubt the maintainer would have made that mistake if they had seen
policy guidance against it.
But that doesn't mean that it should be utterly forbidden.
Ian.
--
Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
