On 12 August 2025 at 13:36, Rebecca N. Palmer wrote: | I've now started looking at this. (As the main issue is that it's an | outdated upstream version, we wouldn't have been allowed to fix it under | freeze.) | | > I'm planning to work on this, possibly in debian-science. | | Is the science team an appropriate place for this package, and if so,
If that is what you prefer, sure. | what is the process for moving the repository from | https://salsa.debian.org/edd/rpy2 to | https://salsa.debian.org/science-team/rpy2 ? The GitLab documentation | for moving repositories | https://salsa.debian.org/help/user/project/import/_index.md#migrate-from-gitlab-to-gitlab-by-using-direct-transfer | seems to be mostly about moving between servers, not moving between | teams on the same server. I don't know. | The question of how many packages rpy2 3.6 is is complicated: | - Still one upstream git repository (https://github.com/rpy2/rpy2). | - Now 3 PyPI packages (both source and binary): rpy2 (which is | near-empty), rpy2-rinterface, rpy2-robjects. | - Still one Python package containing two submodules, rpy2.rinterface | and rpy2.robjects. (The existence of these submodules is not new, only | the fact that they are now separate PyPI packages.) | | Hence, the natural options are: | (1) Keep this as one source package and one binary package, point | d/watch to upstream git, call pybuild 3 times using the -d option | https://sources.debian.org/src/dh-python/6.20250414/pybuild.rst/#L179 | Or, (2) split it into 3 source and 3 binary packages (Debian uses the | import names | https://www.debian.org/doc/packaging-manuals/python-policy/#module-package-names | so the new ones would be named python3-rpy2.rinterface, | python3-rpy2.robjects), keep pointing d/watch to PyPi | | (2) allows a smaller install size for uses that only need | rpy2.rinterface, which is one of upstream's stated reasons for the split | (https://github.com/rpy2/rpy2/issues/1130), but codesearch suggests that | Debian doesn't currently have any packages that would have such a | dependency. | | I intend to try (1) first, but mostly because it doesn't require going | through NEW; I am open to discussion of which we actually want. Agreed. Happy to help. I am traveling this week so I may not get it before early next week. But more than happy to assist with a Python packaging rejig as this is a useful package that has been in Debian for a while. Dirk -- dirk.eddelbuettel.com | @eddelbuettel | [email protected]
