Bug#253511: [PROPOSAL] clarify "package must have a name that's unique ..."
On Thu, Jun 10, 2004 at 12:12:38AM +0200, Bill Allombert wrote:
> On Wed, Jun 09, 2004 at 10:46:30PM +0200, Osamu Aoki wrote:
> > 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.)
>
> Whoever s/he is has no case. GNUstep apps are called with a .app suffix,
> like Terminal.app, it is even advertised in the description:
> "Terminal.app provides terminal emulation in a GNUstep environment."
> So the upstream name is Terminal.app, so terminal seems farther
> from upstream name than e.g. "terminal.app", if it is the intend, and
> adding a prefix like gnustep- make easier to find packages related to
> GNUstep.
Well ... prefix or postfix, it will be nice to see them consistent
across similar packages. "terminal.app" is perfectly acceptable as
*sane* name which is not namespace pollutant.
> Forbidding packages with 2 or 3 letters name because someone want to
> use a generic 8 letters name seems a bit far fetched.
I did not mean this. For this, I am simply asking not to use these very
short names for corner case random packages and commands to avoid name
space conflict. Any better way of addressing this concen?
> Also the issue of package name is parallel to the issue of executable names.
> Given than a package might include several executables, the executables
> namespace (executable in the PATH) is a scarser resource than packages
> names. So I see no benefit most of the time for forbidding packages
> name that are allowed for binary. For example, bc and dc are traditionnal
> UN*X programs, so getting rid of bc and dc as packages name is unlikely
> to improve things.
Of couse not. I think I listed most of these but failed to list bc in
the following section (quoted here).
> * at
> * m4
> * mc
> * dc
> * gs
Again, any better way of addressing this concen?
Reply to: