Re: Namespace pollution
Ian Jackson wrote:
>I propose the following policy:
>No package shall create without approval any command name (or
>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
I can see the sense in limiting punctuation characters, but why allow a
>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
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