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

Bug#253511: marked as done ([PROPOSAL] clarify "package must have a name that's unique ...")



Your message dated Fri, 06 Jun 2008 11:52:17 -0700
with message-id <[🔎] 87abhytmzi.fsf@windlord.stanford.edu>
and subject line Rejected: Bug#253511: clarify "package must have a name that's unique ..."
has caused the Debian Bug report #253511,
regarding [PROPOSAL] clarify "package must have a name that's unique ..."
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
253511: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=253511
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message ---
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



--- End Message ---
--- Begin Message ---
This is a proposal to add some standards to Policy for how packages should
be named to avoid short package names or names that are more common than
the package deserves (camera, terminal, etc.).

The proposal was discussed briefly in 2004 and then the discussion died
without proposed wording or apparent consensus.

This topic is still discussed from time to time on debian-devel, but it's
difficult to write a Policy provision that incorporates the various
common-sense guidelines that go into good package names.  My belief is
that public review on debian-devel with the possible intervention of
ftpmaster where necessary is preferrable to trying to codify rules for
package naming in Policy.

For that reason, plus lack of consensus, I am rejecting this proposal.
This is a soft rejection, meaning that if someone feels strongly about
this proposal and wants to step forward to champion it again, I'd be
willing to reopen the bug.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>


--- End Message ---

Reply to: