Re: potential future namespace clash (Policy 2.3.1)
Osamu Aoki wrote:
> I agree. Common sense tells me that no ordinary package shall use any
> word in "dict". (Maybe these names are OK for virtual package but no
> particular program should use it.)
That is a silly idea. One word: vim
A few more words:
juice hat gawk anarchism aleph cadaver transcriber gadfly sac panorama
ami and synaptic swath zoo audacity glade socket bass unaccent sketch
vigor bonsai zircon encompass unclutter bluefish idle insight bock
speaker rep prosper ne chameleon sam queue edict icebreaker figurine
floater chicken semi motion marbles plan ess magpie yale samba file git
snoopy slay clue ticker chaos pretzel cervisia ant nap melon jade slice
rie pong jargon mew global poster gopher crawl kino jack whisker indent
morse vera horde launcher empire rig tora eject inform predict mona fuzz
aggregate chase grub captain
Um, my grep is only beginning, but I think you get the idea.
I'm sure there are some in other languages too. Unix program names are
historically short, and full of puns. Calling a program something like
"mawk" is not going to confuse anyone (does the package contain an awk
implementation, a bird sound, or a maggot? You decide...), makes no
worse use of the namespace than any 4 letter word that does not happen
to be part of English, is memorable, may be funny, etc. Many of these
words (file, plan, slice, pong) are deeply immersed in unix and computer
history already; using a non-english word package name would engender far
more confusion.
> I think this is not GNUstep policy issue but general issue of package
> name convention. "2.3.1 The package name" section in Policy may need to
> be modified to explicitly forbidding the use of common words as the name
> for the normal package if any other place already defined this.
The case with using "terminal" as a package name is somewhat different
since it can be argued it's confusing, but you're going far overboard
with your suggestion. This is a good example indeed of why a over or
under broad rule in policy often doesn't work, and why we run package
names by the group beforehand instead.
--
see shy jo
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: