Hi! On Sat, 2014-05-17 at 09:49:04 -0400, Thomas Goirand wrote: > On Sat May 17 2014 07:46:16 AM EDT, Ben Finney <b...@benfinney.id.au> wrote: > > Certainly ‘bash8’ carries no reliable connotation of “style checker for > > Bash code”. > > > > > > This is a reference to "pep8" in the Python. > > > > In the Python community, “PEP 8” carries strong connotation of “code > > style conventions for Python code”. It is *only* because of that > > existing connotation that a package named ‘pep8’ implies what the > > package installs. > > > > The same is not true for the name ‘bash8’. It is unreasonable to expect > > the average Bash user looking at package names to get a reference to > > Python conventions. > > > > IMO, the package (source and binary) name should more explicitly carry > > an implication of what the package installs. Perhaps > > ‘bash8-style-checker’ or the like. > > It's ok, since the resulting binaries will be > "python{3,}-bash8". Our users don't get exposed > much to source package names, so I think it's ok > for me to choose bash8 as name to follow the one > upstream, though if you want I can use python-bash8.
I've to agree with the other people complaining, the name is very confusing and as it is, it's a namespace grab. Prefixing it with «python-» only clarifies slightly, but at least it stops somewhat being a namespace grab, but it is still quite confusing. Please try to convince upstream to rename it, and do so in Debian regardless. Something like python-bash-pep8-style-checker would seem acceptable to me, there's probably better, shorter names that could be used though, maybe python-pep8-style-bash, or simply python-pep8-bash. With the «python3?-» prefix being a distribution specific thing. 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. Thanks, Guillem -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140611114947.ga2...@gaara.hadrons.org