Re: domain-specific names for source packages

[Guillem Jover <guillem@debian.org>]

Hi!

On Tue, 2019-10-22 at 20:05:28 +0200, Jonas Smedegaard wrote:
> Let us please all name new source package same as main binary package 
> (not same as upstream project).

I'm not sure, as is, this is a good general rule. I'd reword as, we
should always namespace source packages appropriately, regardless of
the upstream name, ideally with an easy to follow canonicalization
rule (like f.ex. the perl or golang teams use).

> I am concerned about the practice of naming source packages after 
> upstream projects, seemingly common at least for Python packages. 
> Problem is needlessly leads to unintuitive package names later on.

Yes, I've always considered this a very bad practice that I'd really
like, we as a project, stopped perpetuating. I've been bringing up
this issue from time to time (f.ex. in #790399), but unfortunately
there appears to be some inexplicable resistance to this. :( I filed
#791635 some time ago to try to get this bad practice changed in the
python team.

The problem is that in Debian we have a single namespace shared by all
packages and different ecosystems. Most upstream language/domain modules
do not have their language/domain prefixed, but we still do that (in
most cases, except precisely for example python and a few other odd
teams :/) to group and distinguish them, even if they might be very
language/domain specific.

To me, namespacing is very important for at least the following reasons:

  - pollution: so that we squash the possibility for name conflicts in
    the future.
  - relevancy: so that the source/binary names are immediately clear
    to be relevant (or not) for people finding them.
  - grouping: so that every related package is part of, say, the same
    prefix, so they will get printed together, or can be more easily
    searched for, (or even stored more closely in an archive pool).
  - clarity: so that we do not end up with situations like
    src:a → bin:b && src:b → bin:c, which messes up our infra, and
    people's brains.

And because one of the most (if not the most) important resource a
distribution has to curate and arbitrate over is namespaces of many
kinds, source/binary package names, version strings, filesystem objects,
exposed APIs, etc.

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 at least 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.

Thanks,
Guillem