#917103 dh_elpa_test: test bytecompilability

Package:
dh-elpa
Source:
dh-elpa
Submitter:
Sean Whitton
Date:
2021-09-22 13:27:05 UTC
Severity:
wishlist
#917103#5
Date:
2018-12-22 16:53:23 UTC
From:
To:
Hello,

In addition to running upstream test suites, dh_elpa_test could test
whether the package's elisp can be bytecompiled against the version of
Emacs in sid -- Emacs is already a hard dependency of dh-elpa.

This would catch certain classes of bugs earlier.
#917103#10
Date:
2018-12-23 23:20:42 UTC
From:
To:
Sean Whitton <spwhitton@spwhitton.name> writes:

1) What do you think about the idea of adding something like a
   "DESDTDIR" to the generated emacsen-common scripts, then running the
   generated emacsen-install file with DESTDIR=/tmp/something. That
   would be slightly risky in the sense that every time we touch
   maintainer scripts there is the potential for user suffering.

2) Should this be done by dh_elpa_test, or by dh_elpa? I can imagine
   that we might disable upstream test suites but still want to run the
   byte compilation.

d
#917103#15
Date:
2018-12-24 09:33:23 UTC
From:
To:
Hello David,

This is more through testing than just testing bytecompilation, but
seems like a straightforward way to achieve the former.  So, sure, let's
implement it like that.

I think we'd want to keep such a thing out of unstable until after the
release of buster.  That answers your concern about risk, I think.

The important thing is that it could be disabled with
DEB_BUILD_OPTIONS=nocheck; I guess that dh_elpa could just as well
respond to that variable as dh_elpa_test, so it would be fine to put it
in dh_elpa for the reason you give.

Making this work is going to require adding basically everything in
${elpa:Depends} to Build-Depends, because byte compilation will require
loading all the other ELPA libs the package uses.  We want it to be
possible to annotate those additional build-deps with <!nocheck>.
#917103#20
Date:
2021-09-20 14:24:15 UTC
From:
To:
Sean Whitton <spwhitton@spwhitton.name> writes:

By the way, I realized that autopkgtest is already testing byte
compilation, even for tests disabled via debian/elpa-test. Maybe that's
enough, what do you think?

d
#917103#25
Date:
2021-09-21 15:53:10 UTC
From:
To:
Hello,

Could you say more?  How exactly is it testing it?
#917103#30
Date:
2021-09-21 16:26:01 UTC
From:
To:
Sean Whitton <spwhitton@spwhitton.name> writes:
the binary packages are installed and hence byte compiled. Until the
upload 20210916git0-2, racket-mode [1] had this configuration with
Testsuite defined, but disabled in debian/elpa-test.

[1]: https://ci.debian.net/data/autopkgtest/testing/amd64/r/racket-mode/15323474/log.gz
#917103#35
Date:
2021-09-21 22:31:09 UTC
From:
To:
Hello,

Oh great, and if that installation fails the autopkgtest is considered
to fail?
#917103#40
Date:
2021-09-22 13:25:08 UTC
From:
To:
Sean Whitton <spwhitton@spwhitton.name> writes:

Yes, confirmed with debci team, any postinst failure will be (hard) fail
as opposed to network problems which tmpfail.

d