Re: RFC: relaxation of debian-emacs-policy dependency requirements
Rob Browning <rlb@defaultvalue.org> writes:
>> 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.
sure, in that case they can just choose not to call the helper and
implement everything themselves?
> 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").
Cool! :-)
> - something like dh_emacsen_package, which might affect various aspects
> of the package, or
Would this mean that dh would generate the install/remove shell scripts
to each package separately? That does not sound so nice.
> /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.
A symlink sounds almost too clever here :-)
> /usr/share/ec/emacsen-common-package.el
> # Could contain helper functions, and would be loaded from
> site-start.
What sort of helpers do you think should be offered? At least a way to
check if the package is installed so that we don't need to have the
file-exists-p trick in every package separately?
> 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.
Having almost all packages use shared code would improve the quality a
lot. Currently many packages fail in some tiny details (for example they
forget to symlink .el files => emacs help can not find the source code
of a function anymore).
> Of course one disadvantage is that we'd have to be quite careful about
> backward compatibility.
If you are worried about backports.org surely they could easily offer a
backport of emacsen-common?
> 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.
That's fine with me.
-Timo
Reply to: