emacs-filesystem

[Jan Synacek]

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] https://bugzilla.redhat.com/show_bug.cgi?id=661866

Cheers,
-- 
Jan Synacek
Software Engineer, Red Hat

[Michael Schwendt]

On Mon, 04 Jan 2016 15:35:51 +0100, Jan Synacek wrote:

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

[Jan Synacek]

Michael Schwendt <mschwendt(a)gmail.com&gt; writes:

>  On Mon, 04 Jan 2016 15:35:51 +0100, Jan Synacek wrote:
>
> > 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.
>
>  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. 
Ok.

>  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. 
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,
-- 
Jan Synacek
Software Engineer, Red Hat

[Reindl Harald]

Am 05.01.2016 um 11:17 schrieb Jan Synacek:
>  Michael Schwendt <mschwendt(a)gmail.com&gt; writes:
> > 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.
>
>  Any examples of such packages? I still can't imagine how storing emacs
>  specific stuff into emacs directories without requiring emacs could be
>  useful 
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

[Michael Schwendt]

On Tue, 05 Jan 2016 11:17:15 +0100, Jan Synacek wrote:

>  > 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.  
>  
>  Any examples of such packages? 
One was given in 1).

>  I still can't imagine how storing emacs
>  specific stuff into emacs directories without requiring emacs could be
>  useful. 
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

[Jonathan Underwood]

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

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

https://fedoraproject.org/wiki/Packaging:Emacs

[Jan Synacek]

Jonathan Underwood <jonathan.underwood(a)gmail.com&gt; writes:

>  On 4 January 2016 at 14:35, Jan Synacek <jsynacek(a)redhat.com&gt;
> wrote:
> > ...
> > Any comments? Maybe there are still people that were involved with the
> > change?
>
>  Those unaware of history are doomed to repeat it :) 
That's why I'm asking ;)

>  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. 
This is the explanation I was looking for, thank you!

>  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:
>
>  https://fedoraproject.org/wiki/Packaging:Emacs 
Cheers,
-- 
Jan Synacek
Software Engineer, Red Hat