On Wed, May 27, 2020 at 06:07:02PM +0200, Helmut Grohne wrote: > > But the actual split is the last step (4th in your message). So at the first > > step I just add Provides and don't split anything. Right? > > Yes, thank you for reminding me of what I wrote. I'm working on too many > packages in parallel. > > Can we also document somewhere what dependency one should use? I'm not > sure where one would do that though. Possibly a README? Sometimes this > is done in the package description.
I have not documented it yet, but I can do it in the next upload. Should I say something about the extensions? Maybe something like this: | Build-depend on sphinx if your package uses /usr/bin/sphinx-* executables | and does not use Sphinx extensions that depend on anything written in C | or depend on specific Python interpreter architecture in any other way. | Build-depend on python3-sphinx if that is not the case, or if your package | uses Python API of sphinx. Or I should leave only part about Python API, and don't mention extensions because such packages will not cross-build anyway? Please suggest a better wording if you can. > How feasible would it be to ask lintian devs for help? Can we detect > uses of sphinx-build in a reasonable manner to flag missing > dependencies? Maybe. That would be much more visible than the README. > > Can you please quickly look at this commit and say if it makes sense to you? > > > > https://salsa.debian.org/python-team/modules/sphinx/-/commit/c51e0ad4908bb7d6 > > I do not see and issues in that commit. I'd throw it at piuparts before > daring to upload it though. piuparts should be able to catch the worst > issues. Piuparts is run as part of salsa-pipeline (see the green checkmark) :) I have just uploaded sphinx 2.4.3-3 which gets rid of alternatives and adds Provides: sphinx (= ${binary:Version}). -- Dmitry Shachnev
signature.asc
Description: PGP signature
