Emacs packaging guidelines

[Michael Schwendt]

On Thu, 30 Jul 2015 11:39:00 +0100, Jonathan Underwood wrote:

> If there's a general consensus that we want
> to switch back to the splitting out of emacs sub-packages, I would
> definitely support that initiative. But I think (and I'm not speaking
> for them) the FPC would want to see good reasons for flip-flopping the
> guidelines again.

The current guidelines leave the decision to the packager. In cases
where the base package includes much more than an extension of Emacs,
you are free to create an emacs- subpackage, if you prefer that
packaging-style. There is no preference to do so, however.

I still don't see how existing emacs- subpackages "violate" the
guidelines. One may ask packagers to consider getting rid of some
tiny subpackages, but is it worthwhile?

  $ dnf list emacs\*|wc -l
  95
  $ dnf list xemacs\*|wc -l
  27

For less packages, for some time you gain dozens of Obsoletes/Provides
(as well as packagers keeping those for a very long time).

Eventually, an extension included in a base package will grow in size and
will be considered a problem again, raising the desire to split off those
files.

As much as I like a "minimal installation" as a base core for spins and
other products, I'm a much bigger fan of fewer and bigger packages instead
of confronting and overwhelming distribution users with thousands of packages.
You search the package collection and get a thousand [sub-]packages, you're lost.