Re: Binary naming for Django Related Packages

2017-01-23 Thread Scott Kitterman
On Wednesday, January 18, 2017 10:04:24 AM IOhannes m zmölnig wrote:
> On 2017-01-18 07:46, Scott Kitterman wrote:
> > +··named·django_packagename·upstream.··These·are·then·packaged·as
> > +··python3-django-package·and
> 
> please use "package" vs "packagename" consistently.
> e.g. an upstream named "django_packagename" should be packaged as
> "python3-django-packagename".
> 
> It's kind of obvious, but I think the policy should be precise.
> 
> (and probably use "" or "$packagename" or something else to
> mark it as variable)

Thanks.  I went with $name to reduce the number of times we use the word 
package in the paragraph.  Based on your feedback and the lack of other 
feedback, here's what I've committed to the VCS for the next upload (rfcdiff 
html attached).

Scott KTitle: Diff: python-policy.txt.old - python-policy.txt.new
 
 

 
 
 
 
 
 
 
   
   python-policy.txt.old   python-policy.txt.new  
   
  skipping to change at line 516 skipping to change at line 516
   Appendix B, `Packaging Tools').  For example, if Python 3.3, 3.4, and  Appendix B, `Packaging Tools').  For example, if Python 3.3, 3.4, and
   3.5 are supported, the Python statement  3.5 are supported, the Python statement
   
import foo   import foo
   
   should import the module when the program interpreter is any of  should import the module when the program interpreter is any of
   `/usr/bin/python3.3', `/usr/bin/python3.4', and `/usr/bin/python3.5'.  `/usr/bin/python3.3', `/usr/bin/python3.4', and `/usr/bin/python3.5'.
   This requirement also applies to extension modules; binaries for all  This requirement also applies to extension modules; binaries for all
   the supported Python versions should be included in a single package.  the supported Python versions should be included in a single package.
   
  
   As a special exception to the `python3-' and `python-' binary naming  Packages intended for use with Django (`python3-django'/
   policy, Python modules intended for use with Django (`python3-django'/  `python-django') are installed in the same namespace as other python
   `python-django') should add django to their binary package names to  packages for a variety of reasons.  Many such packages are named
   make it clear they are intended for use with Django and not general  django_$name upstream.  These are then packaged as
   purpose Python modules, i.e.  `python3-django-' and `python-django-'  `python3-django-$name' and `python-django-$name'.  This makes it clear
   respectively.  that they are intended for use with Django and not general purpose
Python modules.  Debian maintainers are encouraged to work with their
upstreams to support consistent use of this approach.
   
  3.4. Specifying Supported Versions 3.4. Specifying Supported Versions
  -- --
   
   The `debian/control' source paragraph may contain optional fields to  The `debian/control' source paragraph may contain optional fields to
   specify the versions of Python the package supports.  specify the versions of Python the package supports.
   
   The optional `X-Python3-Version' field specifies the versions of  The optional `X-Python3-Version' field specifies the versions of
   Python 3 supported.  When not specified, it defaults to all currently  Python 3 supported.  When not specified, it defaults to all currently
   supported Python 3 versions.  supported Python 3 versions.

  
  End of changes. 1 change blocks. 
 6 lines changed or deleted 8 lines changed or added
 This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ 
   
   
   


Re: Team maintained packages and git-dpm (was Re: Team upload for python-jedi)

2017-01-23 Thread Barry Warsaw
On Jan 23, 2017, at 02:41 AM, Scott Kitterman wrote:

>Which would be horrible.  single-debian-patch means that to understand the
>upstream modifications, access to the packaging VCS is required.  I think
>that would be a huge step backwards.

Agreed.

-Barry