Hi Andreas, On 10-11-2020 13:21, Andreas Tille wrote: > Yes, that's true but its part of my question: Why should all these > tests be run if the dependencies are not available on that architecture. > Wouldn't it be more sane to check dependencies first before running > a test that will fail for sure? The are not running, clearly, as the text says. But you are wondering if we should not put that text there because it confuses you? Because other people may be wondering why they are not seeing the results. >>> While the package itself is >>> >>> Architecture: all >>> >>> it depends from picard-tools which is amd64 only. >> >> The release team recently swapped i386 for arm64 in >> "NOBREAKALL_ARCHES"[0][1]. That means that arch:all packages need to be >> installable on arm64 and yours isn't. AFAIK. > > OK, fine. For the example drop-seq-tools I could make it > > Architecture: amd64 > > which is solving the current migration problem. However, I'm currently > checking failing autopkgtests for Debian Med packages and add > Architecture fields to debian/tests/control. In most cases this is > perfectly easy auto-detectable from the package dependencies that the > test will fail. Please elaborate. In my experience, things only go ill when package build both arch:all and some arch specific packages, as in that case the migration software just doesn't have enough information available. > I would love to see that dependency issue resolved by > debci in the first place instead of assuming that maintainers will > maintain this inside the control file. Chances are pretty good that > once those dependencies might become available maintainers will simply > forget to add a new architecture to debian/tests/control. That way we > might hide future tests on those architectures from debci. Yes, that's something I worry about too, but I also don't have a better solution with the current information available to the migration software. Obviously we could expend that, but that has a rather high price so we better design it well and balance pro's and con's. Paul
Attachment:
signature.asc
Description: OpenPGP digital signature