Re: RFC: relaxation of debian-emacs-policy dependency requirements
Timo Juhani Lindfors <timo.lindfors@iki.fi> writes:
> Thanks for working on this. Can you comment on
>
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=619480#79
>
> ? Particularly, could
>
> /usr/lib/emacsen-common/packages/install/PACKAGE
>
> in the future just include a call to something like
>
> emacsen-install-helper $1
>
> so that we could get rid of all the copypasted shell script snippets
> that do byte compilation in unique and interesting ways?
This might be a good idea, though I'd probably want to arrange it so
that packages can still handle things themselves if they need to.
> emacsen-startup
> ===============
> 1) Some packages ship /etc/emacs/site-start.d/NNfoo and detect emacs
> version using elisp. Some packages ship /etc/<flavor>/site-start.d/NNfoo
> and do not need elisp check.
> 2) Some packages do the elisp check against debian-emacs-flavor, others
> use plain "flavor" (that's a bug, right?).
I believe so -- it might also be an anachronism (don't recall offhand).
> 3) Some packages handle removed but not purged packages in
> /etc/emacs/sites-start.d/NNfoo and other don't. Some handle it by using
> file-exists-p against an "*.el" file and some against an "*.elc" file.
At the very least, with the new approach, I'd think it should be
possible to rely on (file-exists-p
"/usr/lib/ec/state/package/installed/PACKAGE").
> 4) Some packages call debian-pkg-add-load-path-item or setq load-path
> (bug?) in /etc/emacs/site-start.d/NNfoo and others rely on subdirs.el to
> do the work automatically. Is this perhaps a relic of some old emacs
> version that did not have subdirs.el?
I believe that's likely, and I haven't investigated yet, but we may have
other load-path problems (or relics) that should be addressed.
> emacsen-install
> ===============
> 1) Some packages generate a byte-compilation log and save it in
> /usr. Some put it to /tmp. Some remove it after installation, some
> don't. Some even compress and log rotate byte-compilation logs...
I'm not sure this is a matter for policy, though I suppose we could make
recommendations and perhaps provide some way to easily implement a sane
default.
> 2) Some packages create absolute symlinks to *.el files (against policy)
> and only some use relative symlinks.
> (The above list might contain errors since I didn't write proper notes
> when I went through the packages, sorry about that in advance.
> Do we really want to continue on this path?
> With dh_pysupport there's debian/pyversions that lists the python
> versions that a package supports. Would something like
> debian/emacsversions make sense?
It might. Though I'm wondering which might be best:
- something like dh_emacsen_package, which might affect various aspects
of the package, or
- additions to emacsen-common, or perhaps to a new
emacsen-package-support package. Of course this would require an
additional dependency in each add-on package.
In the latter case, we might have bits like
/usr/lib/ec/emacs-package-{install,remove}-helper
# Could be symlinked from /usr/lib/ec/packages/{install,remove}/PACKAGE
# for packages that just want the default behavior.
/usr/share/ec/emacsen-common-package.el
# Could contain helper functions, and would be loaded from site-start.
...
We might or might not be able to make this latter approach quite as
automatic, but it would have the advantage of putting all the code in
one place (as with shared libs), so we only have to make changes once.
Of course one disadvantage is that we'd have to be quite careful about
backward compatibility.
Offhand, I'm not sure which approach would be better, and before we
attempt anything, I'd want to be sure that there really was enough
commonality among add-on packages for it to be worth the added
complexity.
In any case, I think we may be able to pursue this somewhat
independently of the overhaul, since I suspect that most these changes
would be in addition to those. And where that's the case, I'd prefer to
handle them independently so we don't end up trying to tackle too much
at once. (i.e. perhaps get the overhaul working first, then see how/if
we can abstract the common cases in a way that really helps.)
Thanks
--
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Reply to: