Re: Migration of packages blocked if (Build-)Depends are missing on some test architectures
Hi Paul,
sorry for the late reply.
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'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.
> >>> While the package itself is
> >>>
> >>> Architecture: all
> >>>
> >>> it depends from picard-tools which is amd64 only.
In this example we will now see a change since there was just an upload
of picard-tools which will be arch all ... (see last paragraph of this
mail)
> >> 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.
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.
> > 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.
Than there would be no pressure on maintainers side to actively exclude
these architectures from tests.
Kind regards
Andreas.
--
http://fam-tille.de
Reply to: