Nicholas D Steeves <[email protected]> writes: > Package: dh-elpa > Version: 1.14 > Severity: normal > > Hi David, > > As discussed on IRC, filing this bug. You had also mentioned how this > discussion might lead to an update of Policy and a wishlist bug > against the info package. The resolution of this issue will affect > all elpa-packages that install things outside of their > elpa-src/package-version dir. > > tldr ELPA spec: must directive to install everything to > elpa-src/package-version.
I'm not sure I agree with your fundamental assumptions/definitions here. We're making Debian packages that happen to include some files under /usr/share/emacs/site-lisp. Note that for starters `elpa-src` is a Debian invention. In my view the upstream spec is only applicable to those files that end up in a subdirectory of some element package-directory-list, typically /usr/share/emacs/site-lisp/elpa. And ommitting files from there is fine, as long as it doesn't break the package. > > Obviously we want to do what's best for Debian users, #1, this means > that /usr/share/doc/package should contain the expected documentation. > You'll need to be more precise. Section 12 of Debian policy specifies where various documentation should be installed. > b) It's possible that there exist Emacs packages that will not run > if their bits are installed outside of their elpa-src dir. We > should have a policy on if they should be patched and/or if > symlinks should be provided. Of course this is just part of the > work on packaging software... I think it's a mistake to try and make policy without concrete examples. I'd prefer to avoid non-upstreamable patches, but e.g. it might make sense to patch upstream to look at multiple locations for files, and upstream that. > > #2 I think in most cases it would be better to digress from the > upstream spec and install things using dh_language (the packages I'm > aware of are irony-mode and elpy, but I'm sure there are others). Sure, as I said above, I think your putting too much weight on the idea of an "upstream spec". If you have a concrete problem (like the info thing), we can discuss that. > #3 Info pages. Related to #1 with one caveat: Debian's standalone > info program only support info pages outside of /usr/share/info by > using the INFOPATH variable. If we follow a strict definition of [a] > then symlink /u/s/info/package.info -> elpa-src/package-version/package.info That's not strictly correct. /usr/bin/info also understands directory entries (/usr/bin/info/dir) that point to other places. So perhaps the right invokation of install-info can solve the technical problem. Unfortunately that's hidden away inside a dpkg-trigger. A further complication is that > However, this doesn't handle the case where GNU Emacs provides an info > page for a mode that exists as an elpa-package (eg: org-mode). To be precise, I think your symlink idea will lead to file conflicts for such packages. > Workarounds: > i) make Rob's life difficult by complicating how src:emacs handles Debian > alternatives. I don't think we want to do that. Things are already pretty complicated, and essentially only Rob understands them. > ii) file a bug against src:info and hope that it gets fixed, and that info > gains the ability to read info files outside of the system > default INFOPATH. One option would be to wrap /usr/bin/info in a script that reads /etc/info.d (or wherever) and sets INFOPATH before execing /usr/bin/info.real. In some sense this re-invents /usr/share/info/dir in a potentially less fragile but definitely more debian-specific way. One advantage would be the ability to prioritize packages. It isn't clear to me how to do that with install-info. > iii) add support to dh-elpa for setting INFOPATH using a similar method to > /etc/bash_completion.d (eg: drops a file in /etc/info.d)...I guess this > could be useful to non-dh-elpa-using packages, but I'm not aware of any. I think it'd kindof hopeless to try to ensure correct behaviour of binaries in /usr/bin/ by setting the user environment. There are already a multiplicity of user shells, each with their own startup files and rules, and nothing prevents people from adding new shells. > > Meanwhile, the info issue does not exist for users who use Emacs' > info-mode to view info files... > Indeed, I'm wary of creating a lot of machinery to serve a tiny or non-existent group of users.
