DevHeads.net

emacs-filesystem

Hello,

long time ago, there was a request to create the emacs-filesystem
package [1], so other packages could drop their emacs-specific files
there. I believe it was done the other way around... Those files are
useless without emacs to begin with. I think packages that have emacs
snippets / modes should have a "-emacs" subpackage (or something like
that) that depends on emacs itself.

The following packages now depend on emacs-filesystem (I have omitted
i686 variants for brevity):

a2ps-0:4.14-28.fc23.x86_64
anthy-0:9100h-28.fc23.x86_64
asymptote-0:2.35-3.fc23.x86_64
autoconf-0:2.69-21.fc23.noarch
bigloo-0:4.1a-9.2.fc23.x86_64
clisp-0:2.49-18.20130208hg.fc23.x86_64
cmake-0:3.3.2-1.fc23.x86_64
crm114-0:0-10.20100106.fc23.x86_64
cscope-0:15.8-12.fc23.x86_64
desktop-file-utils-0:0.22-5.fc23.x86_64
emacs-common-1:24.5-6.fc23.x86_64
emacs-pysmell-0:0.7.3-4.fc23.noarch
ftnchek-0:3.3.1-21.fc23.x86_64
gambit-c-0:4.7.9-1.fc23.x86_64
git-0:2.5.0-4.fc23.x86_64
global-0:6.5.1-1.fc23.x86_64
jflex-0:1.6.1-2.fc23.noarch
libidn-0:1.32-1.fc23.x86_64
librep-0:0.92.5-1.fc23.x86_64
mercurial-0:3.5.1-1.fc23.x86_64
mozc-0:2.17.2077.102-5.fc23.x86_64
ninja-build-0:1.6.0-1.fc23.x86_64
nodejs-tern-0:0.7.0-6.fc23.noarch
perl-SystemPerl-0:1.344-2.fc23.x86_64
pypy-libs-0:4.0.0-3.fc23.x86_64
pypy3-libs-0:2.4.0-2.fc23.x86_64
ratpoison-0:1.4.8-2.fc23.x86_64
reposurgeon-0:3.29-1.fc23.noarch
root-0:5.34.32-5.fc23.x86_64
rpmdevtools-0:8.6-2.fc23.noarch
tpp-0:1.3.1-19.fc23.noarch
uim-0:1.8.6-8.fc23.x86_64
why-0:2.35-9.fc23.x86_64
yast2-devtools-0:3.1.36-2.fc23.noarch

I think it would be better that these packages had their emacs
subpackages, instead of the other way around. Not only would that make
more sense, but itw would also resolve the WTF moments when installing
unrelated packages that suddenly require emacs-filesystem to be
installed as a dependency.

Any comments? Maybe there are still people that were involved with the
change?

[1] <a href="https://bugzilla.redhat.com/show_bug.cgi?id=661866" title="https://bugzilla.redhat.com/show_bug.cgi?id=661866">https://bugzilla.redhat.com/show_bug.cgi?id=661866</a>

Cheers,

Comments

Re: emacs-filesystem

By Jonathan Underwood at 01/05/2016 - 07:08

On 4 January 2016 at 14:35, Jan Synacek < ... at redhat dot com> wrote:
This one (pysmell) is a packaging bug - pure emacs add on packages
have no need to install emacs-filesystem (since they require emacs
proper).

Those unaware of history are doomed to repeat it :)

It previously was the case that packages that also shipped support
files for emacs were required to ship the emacs bits in a sub-package.
However, the result was that very few packagers actually complied, and
indeed some just shipped the emacs bits as %docs.

The move to using emacs-filesystem (proposed by me) was a move to be
consistent with vim and xemacs practices. The packages you are talking
about are primarily not emacs add-ons, but packages that also ship a
couple of elisp files to provide auxillary emacs support if emacs is
present on the system. Pulling in the whole emacs stack in such cases
would be overkill. However, having the user have to install endless
emacs-foo packages just to install a few elisp files also seemed like
overkill. The emacs-filesystem approach was a happy compromise, and
already a widely used strategy in Fedora (see vim, xemacs etc). I
still think it's the best approach, personally, as splitting out all
these little elisp files into their own packages just increases
package metadata bloat.

Any change to the current situation would need to be agreed with the
FPC, and coordinated distro wide. Given that we're only now
approaching compliance with the current emacs add-on packaging
guidelines, I can imagine some resistance to the change you're
proposing.

I don't see why there are "WTF moments" when emacs-filesystem i
installed - it contains a few directories, and nothing else.

For info:

<a href="https://fedoraproject.org/wiki/Packaging:Emacs" title="https://fedoraproject.org/wiki/Packaging:Emacs">https://fedoraproject.org/wiki/Packaging:Emacs</a>

Re: emacs-filesystem

By Jan Synacek at 01/05/2016 - 07:46

Jonathan Underwood <jonathan. ... at gmail dot com> writes:

That's why I'm asking ;)

This is the explanation I was looking for, thank you!

Cheers,

Re: emacs-filesystem

By Michael Schwendt at 01/04/2016 - 13:04

Two observations:

1) Emacs extensions are to be put into emacs- subpackages, not -emacs.
It's in the %parent-%child naming guidelines. Note that sometimes this
is implemented as virtual package names, i.e. explicit Provides such as
those in desktop-file-utils.

2) A dependency on emacs-filesystem is primarily for packages, which store
files in those directories, but which do _not_ need Emacs to be installed.
Splitting off emacs- subpackages is not always the most wise/convenient
choice.

Re: emacs-filesystem

By Jan Synacek at 01/05/2016 - 06:17

Michael Schwendt < ... at gmail dot com> writes:

Ok.

Any examples of such packages? I still can't imagine how storing emacs
specific stuff into emacs directories without requiring emacs could be
useful.

Cheers,

Re: emacs-filesystem

By Michael Schwendt at 01/05/2016 - 06:40

One was given in 1).

Well, those packages do more than extending Emacs. They contain things
other than the Emacs extension, and those things don't require Emacs.

Of course, if you strictly want to split off all Emacs extensions into
emacs- packages, it's clear that you cannot imagine a different style
of packaging.

# dnf list texlive\*|wc -l
5162

Re: emacs-filesystem

By Reindl Harald at 01/05/2016 - 06:21

Am 05.01.2016 um 11:17 schrieb Jan Synacek:
any package dropping their snippets into
/usr/share/bash-completion/completions/ - i doubt they all require
"bash" and/or "bash-completion" but if it is used the completions are
present