Re: Namespace pollution

["Oliver Elphick" <olly@lfix.co.uk>]

Ian Jackson wrote:
  >I propose the following policy:
  >
  >No package shall create without approval any command name (or
  >corresponding manpage):
  >
  >1. not matching the regexp ^[a-z0-9]..
  >2. matching ^... if it creates more than two such
  >3. matching [^-+._,a-z0-9], or

Let me restate this in English, to be sure that I understand it:

"No package shall create without approval any command name or manpage less
than four characters long. Commands must consist only of lower-case letters,
digits or the symbols within these quotes: "-+._,".  A package may, however,
create up to two three-character commands without its maintainer's seeking
approval."

I can see the sense in limiting punctuation characters, but why allow a
comma?

  >4. which is a single common dictionary word
  >
  >or any directory directly in /, /usr or /var.
  >
  >Approval will not normally be granted except for the use of capital
  >letters where there appear in an upstream package command name.
  >
  >The fact that an upstream package uses a short or otherwise poor
  >command name or placement will not in itself be a justification for
  >using that name in Debian (nor will reasining derived from purely that
  >fact, such as that users will be `expecting' the short name).

  >A sound technical reason for the shortness of the command may be
  >considered relevant.

Many short names are part of traditional Unix; I can't think of a sound
technical reason to support _any_ name, except perhaps '['.  Names are for
people, not programs.  I would certainly be unhappy to have ls changed to
list or dir to conform to this policy.
 
I just don't see the need for being so restrictive.

-- 
Oliver Elphick                                Oliver.Elphick@lfix.co.uk
Isle of Wight                              http://www.lfix.co.uk/oliver

PGP key from public servers; key ID 32B8FAA1