Bug#909453: site of discussion for Debian digressions from ELPA spec
Nicholas D Steeves <nsteeves@gmail.com> 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.
Reply to: