Namespaces
==========

This is a dump of similar conversations I've had with people or over the
mailing lists, which needs consolidation and cleanup, and probably be
posted somewhere more visible.


coinor-* packages
-----------------

Well, I think consistency distribution wide is way more important than
consistency between a binary set from the same source package, and
that's what a distribution is all about, integrating random pieces of
software in a unified manner.

You mention the prefix to avoid package name collision, and that's what
I was referring to with the namespace comment, if you truly want to
avoid collisions, the only sane option is to do that in the SONAME.
There's for example the coinor-libvol0 which has a pretty generic
SONAME (libVol.so.0). I'd recommend talking with upstream and asking
them to rename all libraries like libCoinOrVol.so.0, libcoin-or-vol.so.0
or something along the lines, and that would also fix possible problems
in other distributions as well.

> [Current problem?]

Not now, although I think taking care of the namespaces (package names,
SONAMEs, binary names, etc) before it's a problem is really important
for everyone (upstreams, distributions, users, etc), by avoiding too
generic names, conforming to namespaces conventions, not reusing names
from other projects, etc.

Dealing with this after the fact tends to be rather painful for everyone,
users who have gotten used to a specific name, software that relies on
it, confusion on search engine hits, incompatibilities between
distributions being forced to use different names than upstream, etc.

Dictionary words <20120724061134.GA5535@gaara.hadrons.org>
----------------

While I agree that when it comes to a distribution it's really very
important that we take care of the namespace_s_, which are not only
package names, but command names, shared library names, C header file
names, etc, I strongly disagree a simple rule as “do not use common
dictionary words” would be good or appropriate at all. Namespaces are
all about context.

One thing is to name your text editor just “editor” or your browser
“browser”, the other is naming it dolphin, which is also a common
dictionary word.

Another difference would be if your implementation is either generic
or field specific, an example could be libmaildir4 which used to be a
KDE specific library to handle Maildir mail boxes, if that would have
been a generic low-level toolkit-neutral implementation, I think it
would have been ok-ish, but not as it was (which ideally should have
been named libkmaildir4). The same applies to command-line tools, if
your tool is called «add» but is used for stuff related to chromosome
additions then I'd say that's really not appropriate, but if it's used
to compute the addition of two files filled with numbers then that'd
seem better (preferibly if it comes from an existing base package).

Or if someone devises a new tool named “feather” and suddenly it
proves to be very useful, and lots of clones appear, then those would
be feather-clones, and it would not be appropriate to make the
original change its name, in the same way the original vi was just
vi, and the subsequent clones got their variant names (nvi, vim, etc).

And we have to take into account that a huge amount of computing terms
come from metaphors from real life or other fields or simple reuse of
generic words, so outright banning common dictionary words would mean
we cannnot name new things to come.

Upstream packaging <20130424194348.GA32703@gaara.hadrons.org>
------------------

requires curating sane namespaces, be them on the
package/project names, on the version strings, on the filesystem (by
avoiding file collisions, using alternatives or diversions), on exposed
programming interfaces, etc;

Bug#748383: ITP: bash8 <20140611114947.GA2614@gaara.hadrons.org>
----------------------

Also just following upstream when it comes to naming be it for source
or binary packages is not wise in many cases. Lots of upstreams create
packages or language modules in language silos, where those names are
implicitly namespaced by being part of that language community/portal
for example. Having Http be a perl module is fine, the same for a
python or ruby module, not so much when it comes to integrating it
in a general purpose distribution. Why should the http source package
name be the perl implementation? Even if that source provided modules
for many languages, why should it take over the canonical protocol
name for its source package? Also the source package name is really
pretty visible in many places in the distribution.

The current practice of many python modules to just use the upstream
name as the source package name is a namespace grab, wrong and unfair
to the rest of the distribution, some quick examples to illustrate:

  appdirs argvalidate audioread distlib

I wish other language teams in Debian followed the perl lead here.

+++

OCaml is also a good citizen.

Also this grabs the non-namespaced name for actual programs for example.

Bug#745347: ITP: releases <20140611104248.GA2457@gaara.hadrons.org>
-------------------------

Or python-sphinx-releases, python-sphinx.releases or something like that,
there's few precedents for the former on the archive already. I think it
would be nice to discuss this on the debian-python list to try to come
to an agreement on the namespace, because simply using the non-namespaced
upstream module name is really not good for the overall distribution.

Please make sure to rename both binary and *source* packages.

> Note: I'm not a DD, if no DD is complaining then maybe it's not confusing.

I just saw it in NEW and I've to agree it is very confusing. I think
people might usually notice when it's already in the archive which
implies going through NEW again, package removal requests, possibly
transitional packages, etc, which might deter them from mentioning it
or filing bug reports.