The .el files are in the binary package, but I guess the postinst
doesn't follow debian emacs policy to get the files byte compiled and
installed in the right place.

- -- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (900, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 4.11.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE=en_CA:en (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages a2ps depends on:
ii  file       1:5.30-1
ii  libc6      2.24-12
ii  libpaper1  1.1.24+nmu5
ii  psutils    1.17.dfsg-4

Versions of packages a2ps recommends:
ii  bzip2           1.0.6-8.1
ii  cups-bsd [lpr]  2.2.4-3
ii  wdiff           1.2.2-2

Versions of packages a2ps suggests:
ii  emacsen-common                       2.0.8
ii  ghostscript                          9.21~dfsg-1
pn  groff                                <none>
pn  gv                                   <none>
pn  html2ps                              <none>
ii  imagemagick                          8:6.9.7.4+dfsg-15
ii  imagemagick-6.q16 [imagemagick]      8:6.9.7.4+dfsg-15
pn  t1-cyrillic                          <none>
ii  texlive-binaries [texlive-base-bin]  2017.20170613.44572-3

- -- no debconf information
-----BEGIN PGP SIGNATURE-----

iQGzBAEBCAAdFiEE3VS2dnyDRXKVCQCp8gKXHaSnniwFAlmD5j0ACgkQ8gKXHaSn
niyeDgv/ZLJ5lU8bfqLC/iLvOidJF9PLuWDwhpTjHOttUivgpPgS7vXOXynQDs33
xEG8FFZ6FCBC+hlrJ8ECxHcktcYU4vrUPtjdnYgeNXTDG1Abbc/sdLeRgJirQuLD
P3nDZGU1olwqDprgTsBkqw2ESTDFAvG1bhrvIbDtUII9UEYwxhpzrVp3J4qsZ/2G
yJzA3nRcF2LHINlG8xac6YRxF8ccUkxhNc/PMJfTKpLfPkX5OBpFtaSf9ofIe1xi
qKgiBZp2lXeu4dQycQDGE21dVqxAc/SruTR89KOPv1RovPYajzvwDYEpg4W8nkK7
rCwEe6rqvYHiMllfXz52ZmT+yQlP1CaN6v2ASyzIgWChrZyRhvgJRc1hHzQspWy7
xZSEu9qYP+8DCkVHONZKAHShwJEoDMtgXMF5AEeS4I8V2tBNNclGaBa2lmv7FmkH
wwzgLeNptSM/CXzf2hcw4kjBCFlDL4wcGskF+BfJJgQiY+twlWvsJJH3rXS7c5n3
z9HLStSz
=uh0R
-----END PGP SIGNATURE-----

In the QA upload I just did, I thought about weather to fix this by
converting to dh-elpa based on the lintian warning:

https://lintian.debian.org/tags/emacsen-common-without-dh-elpa.html

  "Please consider transitioning the package build to use dh-elpa,
  unless the package is required to work with XEmacs."

But it wasn't clear to me, a humble QA uploader barely familiar with
emacs, XEmacs, and .el files at all, weather it is required to work with
XEmacs or how I would figure that out.


The lintian warning I saw helpfully provided a link (that I managed to
ignore until just a few moments ago) to:

https://wiki.debian.org/Teams/DebianEmacsenTeam/elpa-hello

But that seems geared towards a package actually shipping a package just
for elpa, as opposed to a package that happens to ship a stray, lonely
.el file.


And with a very brief and casual search, none of the above linked to a
Debian Emacs Policy, though if I spent even more time looking for it,
maybe I would find it helpful... oh look, the emacsen-common package
ships /usr/share/doc/emacsen-common/debian-emacs-policy.gz ... that is
probably it.


Well, if anyone more courageous than me wants to take a stab at making
a2ps comply with debian-emacs-policy, maybe my meandering response will
help you find your way to a patch and/or upload.


live well,
  vagrant

Vagrant Cascadian <vagrant@debian.org> writes:

The last time I checked, the basic technology used by dh-elpa (namely
'package.el') is not supported by XEmacs.

FWIW, I had understood that XEmacs would not be shipped in Bullseye
(last upstream release in 2014 iirc), but I'm not directly involved, so
I don't know exactly what is going with XEmacs in Debian.