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

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

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