On 11/28/2016 05:11 PM, Scott Kitterman wrote:
> I've recently done some Django related packaging for the first time and 
> noticed that we have organically (as far as I can tell) grown a slightly 
> different naming convention for such packages.  Instead of python*-foo, we 
> use 
> python*-django-foo.
> I think this is a reasonable approach and followed it in the new packages 
> I've 
> recently done.
> I decided to check and see how common the approach is.  Here's what I found 
> in 
> Sid:
> Start with django: 7
> Start w/django, not transitional: 2
> Start with django3: 0
> Start with python-django (excluding -doc): 136
> Start with python3-django: 84
> I think it would make sense to add this to the Python policy so how we're 
> doing it is documented.  I am attaching a proposed diff.  I made it a should 
> because there are two non-DPMT packages that don't follow this rule and I 
> think it's late in the cycle to be adding to must policy requirements.
> Please let me know what you think.  I'm open to suggestions on wording.  I'd 
> like to get this done in the next week and do a python-defaults upload with 
> this and a few minor (non-policy) changes that are pending.
> Scott K
> @@ -534,6 +534,13 @@
>       This requirement also applies to extension modules; binaries for all
>       the supported Python versions should be included in a single package.
> +     As a special exception to the `python3-' and `python-' binary naming
> +     policy, Python modules intended for use with Django (`python3-django'/
> +     `python-django') should add django to their binary package names to
> +     make it clear they are intended for use with Django and not general
> +     purpose Python modules, i.e.  `python3-django-' and `python-django-'
> +     respectively.

IMO, what should drive the binary package name is what upstream sets as
egg name, so that we don't have to do pydists-overrides. The current
global Python policy is to use the Python module names (ie: what one
would write when doing an import), which IMO is wrong, because we got to
do so many substitutions to have the Depends correct. If our policy was
to use egg-name for package names, we wouldn't have any substitution to

Anyway, I don't see why Django modules should be an exception to any
rule we choose. If upstream is missing the "django-" prefix, then we
should suggest it.

Thomas Goirand (zigo)

Reply via email to