Hello Paul,
On Fri, Aug 03, 2018 at 01:09:20PM +0200, Paul Gevers wrote:
> Hi Ralf,
>
> On 03-08-18 11:46, Ralf Treinen wrote:
> >>> An alternative solution in my use case would be to use the "skippable"
> >>> restriction, apt-get install the backend in the test and exit 77 when
> >>> this fails, but this would mean using root access without a good reason.
> >>
> >> Ok, so you actually don't want flaky, but you want to make your test
> >> depends arch aware, (Depends: x y [amd64]),
> >
> > no, I do not want to hardcode in my package the list of archtictures on
> > which my Recommended packages build or do not build. This would be a
> > maintenance nightmare.
>
> Ack. But let's distinguish solutions between stuff that works now and
> the final desired situation. My proposals works now, with relatively
> little effort in the test (the check if it is installed).
OK. It is true that I was looking for a permanent solution, but as long
as ci.d.n is only testing on amd64 there is no urgency for debian itself,
as all of why3's alternative recommends should be available on amd64. The
situation is however different for Ubuntu since they run ci tests on
all their architectures, which is great.
> Maybe, but I am just thinking out load, what we are searching for is a
> way to say in the test definition: only run on these architectures. One
> of the ways of saying that would need to be: where packages ((x and y)
> or z) is available. Well, writing it down matches close to what you
> want, maybe we want a restriction that says "skippable if dependencies
> are unsatisfied". That way as the maintainer you are in control, and we
Yes, indeed, that is the kind of solution I was thinking of.
> don't need to make this the default (as explained, that would be bad).
> On the other hand, if you have this, it would make that test insensitive
> to real dependencies issues, but the migration software should handle
> those anyways.
One could try to catch the erroneous test dependencies on the level
of the ci framework by checking if a test is skipped on *all* architectures
and in all distributions (sid,testing), and raise a red flag if that is the
case.
> I think, but I can't find it in documentation, is that you can also have
> this *now*. (You proposed this in your mail from May, except we didn't
> have the skippable then) Make the test skippable, add an alternative
> depends in your test that is widely available (e.g. why3 in your case),
> check if the first alternative is available and if not exit 77. This
> relies on apt in a way that I can't find documented. I mean, as a human
> reader I would say the latter alternative is already (going to be)
> installed, so why bother installing the first. We would need to test if
> apt behaves as we suspect, otherwise, depend on something unrelated.
Yes, that is what we discussed back in May, and I think I will for the
moment go back to that solution. However, this means depending on some
resolving strategy that we currently observe with apt and which I also
think is not documented, so this is fragile. But it should do for the moment
until a permanent solution is found.
> >> in your test check if your
> >> dependency is installed and if not, exit 0 (or 77 with skippable).
> >
> > This works only if the testbed will install as many of my *alternative*
> > Recommends as possible.
>
> Why?
I probably misunderstood you here, but let me nevertheless explain what
I meant here: why3 recommends
alt-ergo | cvc3 | cvc4 | ...
which means that apt, when installation of recommends is enabled, will only
install one of these (probably the first). If each of my tests
why+whatever just checks whether whatever is installed, without having it
as a test dependency, this means that the first test why+alt-ergo will find
that alt-ergo is installed and actually run the test, but the other tests
like why+cvc3, why+cvc4 will find that cvc3, cvc4 are not installed and
will just skip. That is what I meant when I said that these tests would be
no longer useful. However, that would work if apt could be convinced
to try to install a maximum number of the alternative recommends at the
same time, and not just one.
Thanks for your time in discussing this issue! -Ralf.
