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

Re: Unversioned emacs packages uploaded to experimental



Agustin Martin <agmartin@debian.org> writes:

> 2018-05-28 18:40 GMT+02:00 Rob Browning <rlb@defaultvalue.org>:
>>
>> It's likely that you'll see some trouble with add-on packages during the
>> install.  In my case, it was with packages that explicitly ignore the
>> emacs flavor in their maintainer scripts.
>>
>> Please report bugs against any you notice, perhaps mentioning the key
>> fact that "emacs" is now a concrete flavor, and so add-on packages
>> shouldn't ignore it anymore.  If appropriate, they can guard their
>> changes via "Depends: emacsen-common (>= 3.0.0)".
>
> Hi, Rob and others,
>
> I tried to just remove the emacs flavor exclusion in
> dictionaries-common, but that led to a problem with unversioned Emacs
> in experimental (#901575)
>
> dictionaries-common ships some .el files for Emacs and XEmacs use.
> Emacs only needs debian-ispell.el, but XEmacs also needs ispell.el and
> flyspell.el for the spellchecking integration to work.

I hope that xemacs support is not too much extra work.  I think
xemacs21-mule now has less users than emacs23 [1], which is present only
in oldoldstable.  Dropping xemacs support would allow you to use
dh-elpa, and avoid these particular problems. Of course small groups of
users may still be unhappy and complain, it's your call.

> I could just avoid symlink setting for unversioned Emacs, but there is
> an aditional problem with it. For byte-compiled files to be available
> I'll need to add that path to the search list, which will have as a
> side effect that ispell.el and flyspell.el will be used by Emacs
> instead of those provided by the package. No problem for XEmacs.

Are you worried here about emacs loading the source files instead of the
byte-compiled ones?  By default emacs loads the .elc even if the .el is
newer (see the variable load-prefer-newer). It's also usually not that
big a deal to skip byte compilation (the exception being some uses of
macros). You could try just putting the .el files in the load path and
see how that goes. I just tried ispell-buffer uncompiled, and it seems
fine.

>
> I am thinking about putting the .el files under
> /usr/share/dictionaries-common/emacs/site-lisp and set symlinks to the
> contents I need from
> /usr/share/{emacs,xemacs21}/site-lisp/dictionaries-common/.

I don't see any problem with this, but I'm not an emacsen-policy expert.

> This has an additional advantage. Some people use personal Emacs
> builds and there is sometimes a subdirs.el in
> /usr/share//emacs/site-lisp/, resulting in ispell.el and flyspell.el
> being loaded even if it was not intended.

This seems related to the discussion above about byte-compilation, I'm
not 100% sure. I would say that user modification of files in
/usr/share/emacs/site-lisp is not supported (if that's what your
discussing).



[1]: https://qa.debian.org/popcon-graph.php?packages=+xemacs21-mule+emacs23+emacs25+emacs24&show_vote=on&want_legend=on&want_ticks=on&from_date=&to_date=&hlght_date=&date_fmt=%25Y-%25m&beenhere=1


Reply to: