[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#253511: [PROPOSAL] clarify "package must have a name that's unique ..."



Package: debian-policy
Version: 3.6.1.0
Severity: normal

Currently policy states:

|3.1. The package name
|---------------------
|
|     Every package must have a name that's unique within the Debian
|     archive.
|
|     The package name is included in the control field `Package', the
|     format of which is described in Section 5.6.6, ``Package''.  The
|     package name is also included as a part of the file name of the `.deb'
|     file.

Here there is no restriction for the package name being *sane*.

On the other hand, "3.2. The version of a package" has
...
|     If an upstream package has problematic version numbers they should be
|     converted to a sane form for use in the `Version' field.
                     ^^^^

This gives a good ground for not choosing bad version naming.

Most of us think that keeping *unique* name requires the choice of
package name to be *sane* :)  (Yes, I know a gnustep application
packager disagreed.)

We need to clarify the position of Debian on 3.1.

Let me propose:

|3.1. The package name
|---------------------
|
|     Every package must have a name that's unique within the Debian
|     archive.
|
|     The package name is included in the control field `Package', the
|     format of which is described in Section 5.6.6, ``Package''.  The
|     package name is also included as a part of the file name of the `.deb'
|     file.
|
+     If an upstream package has problematic name they should be converted
+     to a sane form for use in the `Package' field.
+
+3.1.1. Package name guidelines
+------------------------------
+     Use of common sense to avoid name space pollution of package names
+     are encouraged.  The package name should be longer than 4
+     characters and should not use generic words. Use of prefix to
+     identify name a group of softwares which are applicable only for 
+     the subset of the Debian environment is encouraged.  Some
+     traditional popular programs may be exempted from these restriction.

I welcome better English but I think I made my intent clear with above.
I think that the choice of command name should follow similar restriction.

NB: (Here is more of my thoughts ...)

I am not expecting this to be strictly applied from Sarge.  This is
to quiet future flame war on package name for post-Sarge.

I see no problem with followings as package name:
  * at
  * m4
  * mc
  * dc
  * gs
  * lv (Maybe because I am Japanese)
  * nvi
  * g++
  * gcc
  * ftp
  * inn
  * lpr
  * ppp
  * ssh
  * screen

There are 51 packages with 2 characters and there are 356 packages with
3 characters already.  (unstable/main)  Here are 2 character package
names:

   af an at bb bc bl cu cw dc di dx e3 ed ee es fv gb gq gs gv ht hx im
   kq le lv m4 mc mp nd ne nn pi pv qe qm rc re ri sc sl sn sp tf ud vh
   vm wl wv xt yh

I doubt how many packages of these deserve to use 2 character name
space.

I want to see following proposed/existing package names are changed:

  * camara        --> gnustep-camera
  * latexservice  --> gnustep-latexservice
  * terminal      --> gnustep-terminal
  * connect       --> gnustep-connect
  ...

(Here I do not care prefix being gnustep- or gnustep-client- )

Generic words may be used for virtual package names if needed.

If anyone has better way to stop nonsense package names, I will be
open for suggestion.

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.6.6-1-686
Locale: LANG=C, LC_CTYPE=en_US.ISO-8859-1

-- no debconf information

-- 
~\^o^/~~~ ~\^.^/~~~ ~\^*^/~~~ ~\^_^/~~~ ~\^+^/~~~ ~\^:^/~~~ ~\^v^/~~~ +++++
        Osamu Aoki <osamu@debian.org>  Brussels Belgium, GPG-key: A8061F32
 .''`.  Debian Reference: post-installation user's guide for non-developers
 : :' : http://qref.sf.net and http://people.debian.org/~osamu
 `. `'  "Our Priorities are Our Users and Free Software" --- Social Contract




Reply to: