Hi Matthias, Matthias Klose, on 2021-04-05: > On 4/5/21 3:30 PM, Andreas Tille wrote: > > On Mon, Apr 05, 2021 at 02:46:41PM +0200, Matthias Klose wrote: > >> The autopkg tests don't run with the same dependencies as during the > >> build. Just > >> noticed because the python3-renderpm dependency seems to be necessary with > >> the > >> reportlab package from experimental. > >> > >> But in general, please run the autopkg tests with the same packages as done > >> during the build. > > > > Could you please be more verbose. The Build-Depends and Depends string > > do not do any specific version specification. Python3-reportlab was > > added to Depends since it is really needed while python3-renderpm is > > fine as "Suggests". Which change would you recommend to solve that bug? > > please re-read. This is not about package dependencies or suggestions. All the > <!nocheck> build dependencies should be added as autopkg test dependencies to > test the same stuff you test during the build, unless there's a specific > reason > not to do so.
One of the uses we have of autopkgtest, among other things, is to check that there are no missing dependencies in the packages; so I think that is one reason why the <!nocheck> build dependencies are missing. In biopython context, the package might have different behavior, depending on available tools on the machine. So I agree it makes good sense to have testings with different combinations of packages installed on the target system. I actually implemented a second test, in addition to the existing one, which includes all the test check dependencies, and which should make it in an upcoming update, after bullseye release. The only concern I have is the maintainability of a full_suite test, since there are no needs-build-deps restrictions, and I don't really expect it would happen, since deprecation of needs-recommends (IIUC, it caused problems of reproducibility of issues in autopkgtests). However, it might also highlight newer missing tools when proceeding to upgrades, so this might be a non-problem. Any ways, this package has a lot of reverse dependencies, so we might be better off having too many tests than not enough. Have a nice day, :) -- Étienne Mollier <emoll...@emlwks999.eu> Fingerprint: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da Sent from /dev/pts/2, please excuse my verbosity.
signature.asc
Description: PGP signature