[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#917103: dh_elpa_test: test bytecompilability

Hello David,

On Mon 24 Dec 2018 at 08:20am +0900, David Bremner wrote:

> Sean Whitton <spwhitton@spwhitton.name> writes:
>> 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.
> 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.

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.

> 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.

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>.

Sean Whitton

Attachment: signature.asc
Description: PGP signature

Reply to: