Mathias Behrle <mathi...@m9s.biz> writes: > I am packaging from release tarballs published on downloads.tryton.org > resp. pypi [1].
(I don't know what you mean by “resp.”, that's not something I recognise as English. I assume these are simply tarballs published on PyPI by the upstream developers.) > Those tarballs are created with the standard command > > $ python setup.py sdist > > So upstream is shipping proper source tarballs (in a way;), the > inclusion of generated non-source files comes from setuptools. Okay, so removing that in the ‘debian/rules clean’ target is normal and common. You can instead, if you choose, remove them in the ‘uscan --download’ step with a repack command (by re-packing pristine upstream version “1.2.3” to upstream version “1.2.3.ds1”, for example). See the ‘uscan(1)’ man page where it talks about “a third parameter (an action)”. This all means, of course, that you should work from the published source tarballs, and not attempt to track the resulting files in VCS. > It doesn't happen when using distutils, but I don't think I will have > success, if I wanted upstream to change the working setup from the > de-facto standard setuptools to distutils [2][3]. Since Distutils is the officially supported standard for Python, it would be worth trying to convince your package's upstream to migrate to that. But not strictly necessary, if you are okay with handling the unofficial Setuptools. -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/7w7gbxtqfp....@benfinney.id.au
