Hi Christoph,
On 21.09.20 18:03, Christoph Groth wrote: > Hello, > > As mentioned [1], Steffen Möller and Andreas Tille helped to finish the > packaging of Tinyarray [2]. Here, I would like to continue off-list > discussions we had. > > Andreas Tille wrote: > >> The cythonized files are not really needed for Debian packaging. Its >> mandatory to re-build them in the package build process anyway. >> Otherwise this is considered as the usage of foreign binary code. >> Thus it makes sense to use a tarball without cython results. > Actually, tinyarray is a pure C++ Python extension. There’s no Cython > in there. My remark on upstream tarballs containing cythonized files > was more general, extending to the other packages that I intent to > package, like Kwant. > > Kwant contains substantial amounts of Cython code, and since the > beginning we have been following the advice of Cython documentation [3]: > > “It is strongly recommended that you distribute the generated .c files > as well as your Cython sources, so that users can install your module > without needing to have Cython available.” > > But for Debian it is of course possible to re-cythonize. However, this > does not change the fact that the upstream tarballs contain the > cythonized files. And I always believed that Debian is very careful > (not to say pedantic) about upstream tarballs and keeps them as > immutable artifacts. Nothing is patched and hidden (all patches go to debian/patches) but it is ok to just skip a few files that upstream otherwise ships. For instance, some upstreams have autoconf/-make generated files in their source tree. Just anything that is machine-generated should go and cython, i.e. cython3 now, becomes a build-dependency. Please have a look at d/copyright files that specify "Files-Excluded" (man uscan) . When d/watch then features a "repack,repacksuffix=+ds,dversionmangle=auto" you are indicating with the "+ds" in your version that the source tree is not complete and uscan prepares the source tree for you as instructed by Files-Excluded. >> If you are tagging releases properly in your >> >> https://gitlab.kwant-project.org/kwant/kwant >> >> I would prefer this over PyPI. But using PyPI is fine was well. > Sure, the tags are correctly signed and we keep them immutable. We’ve > been using PyPI in debian/watch, since it is likely *even* more > persistent ;-) than our own gitlab instance. > > However, the only officially released tarballs are those to be found on > PyPI and on https://downloads.kwant-project.org/. PyPI is fine. You are the maintainer - you decide, really. > Is it OK use the gitlab-generated tarballs as upstream for Debian? You specify in d/copyright how to exclude all the Cython-generated files and then have uscan repack a .xz source tree that you then gbp import-orig --pristine-tar ... into your local git repository. > I guess that’s fine, other than that the upstream tarball for a given > version will then differ from the one used by everyone else. Hm. Yes. Let alone because of the cython-removal. The xz format is more efficient than the gz, you will like it. Otherwise set compression=gz in d/watch. >> I just sponsored tinyarray. In principle I would love if Christoph >> would use >> >> https://wiki.debian.org/DebianPureBlends/SoB >> >> It perfectly fits since the its scientific software. May be even >> tinyarray would fit in some of the Debian Science Blend? The final >> target will fit in any case and I'd strongly recommend to use >> a repository under science-team for its packaging. > I’m happy to follow any guidelines, I’m just a bit confused with what > “DebianPureBlends” has to do with packaging tinyarray for Debian. > I thought that Debian Pure Blends is an umbrella-term for specialized > sub-distributions of Debian. > > I’m also OK with moving tinyarray to debian-science if this is useful > and possible. We just had a series of Python packages moved from med-team to the Python packaging team - I think it is fine as it is. We can address bits together via skype or so if I was unclear or you get stuck for whatever reason. Best, Steffen > [1] https://lists.debian.org/debian-science/2020/09/msg00043.html > [2] https://salsa.debian.org/python-team/modules/python-tinyarray > [3] > https://cython.readthedocs.io/en/latest/src/userguide/source_files_and_compilation.html#distributing-cython-modules
