Hi Andreas, On 18-11-2020 12:45, Andreas Tille wrote: > On Tue, Nov 10, 2020 at 09:02:56PM +0100, Paul Gevers wrote: >> 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. > > Well, the test is not actually run - since it can not be run. In those > cases we see a long log to create the debci environment and try to > install the package ... which fails. I have the strong impression that we're talking past each other. The log message that you quoted in your initial e-mail said "uninstallable on arch *, not running autopkgtest there". This means the test is not triggered *and* that fact will *not* block the package. However, you are now saying we're scheduling the test which fails. That's a completely different category. > I'm wondering whether it would > be easy to find out in advance whether it is possible to install that > package on that architecture (for instance by an UDD query whether > all dependencies are available or whatever) and just stop if it turns > out that the package is not installable. Yes, we can (and do) that, but what then? If the non-installability is a regression, we should block the package. If the non-installablility is already existing, the package should just move on. We already do that (or at least try very hard). So, which *exact* use case do you consider here (real life examples help). >> 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. > > As I tried to say above: I would prefer to find out before apt runs > in a fully setup test environment whether the package is installable > at all. As I tried to say above, we already don't schedule the test in *most* cases and as far as I'm aware, we only have some issues where arch:all packages are involved. In some cases, I don't think there is a "right" answer, so we need to get the most acceptable solution. >>> 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. > > My idea is to find out whether a package is installable on some > architecture and add a new test result say "NOT_INSTALLABLE" or > "NOT_INSTALLABLE_ON_ARCH" which is considered "neutral" as test result. We don't schedule those cases we can catch. So we don't need to have a new state. If we can find the exact problem you're describing we can try to add it to the set we don't trigger. (By the way, are you aware of the skip-not-installable restriction? It's not great, as it hides real issues, but could be a solution for a class of packages, maybe the ones you worry about). > Than there would be no pressure on maintainers side to actively exclude > these architectures from tests. Indeed. That should be hardly needed. Paul
Attachment:
signature.asc
Description: OpenPGP digital signature