Bug#741573: Two menu systems

[Ian Jackson <ijackson@chiark.greenend.org.uk>]

Lisandro Damián Nicanor Pérez Meyer writes ("Bug#741573: Two menu systems"):
> Then we have a "double standard" here. For some cases we (as in "the
> project") consider "should" as Stuart and I described it before, but
> we do *also* consider it a "may" for some cases, as Ian has just
> pointed it out.

Can you come up with any examples where "should" is used in a way that
_does not_ permit a maintainer to disregard it if it appears to be a
more work than they care to put in ?

I had a quick look at an arbitrarily chosen section (10, as it
happens, on "files"), and there are a lot of uses of "should" which
are probably bugs if not followed - but none of those are any
particular effort to comply with.

Here are the shoulds that seem to me like they might involve some
> actual effort:

  10.1
  | builds to include debugging info by default
  | builds should turn on warnings

  10.2
  | static libraries not to use -fPIC unless discussed
  | scripts to use set -e (not limited to Debian-authored ones!)
  | perl scripts to check errors (not limited to Debian-authored ones!)
  | avoid [t]csh for scripting (not limited to Debian-authored ones!)

  10.7.1
  | script containing config should be treated as config

  [ok, bored now]

There are a couple of these that probably should be "must".  For the
rest it is IMO acceptable to upload a package which violates them, if
the maintainer doesn't feel like tackling that particular problem.

Foe example, if the upstream build system is particularly intractable
and makes it difficult to sanely specify compiler flags, then
it's acceptable (but of course undesirable) to let the upstream build
system have its way.  If the upstream package comes with tcsh scripts
or perl scripts that have shoddy error handling or sh scripts that
don't say set -e, those things are probably bugs - but I don't
necessarily expect the maintainer to fix them all.

Ian.