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