#68 Modify Emacs packaging guidelines to reflect new (x)emacs-filesystem packages
Closed: Fixed None Opened 10 years ago by jgu.

Consider the following very common situation: a package's principal functionality does not require (X)Emacs, but the package also includes some auxiliary Elisp files to provide support for the package in (X)Emacs.

Presently the (X)Emacs guidelines require that the package split those Elisp files out into a subpackage (called emacs-foo) which Requires (X)Emacs. This was done to avoid the main package dragging in (X)Emacs and related dependencies for when a system administrator doesn't want to install (X)Emacs; this is necessary as the (x)emacs-common packages own the /usr/share/site-{lisp|package} directories where the Elisp files would be installed.

Ville Skytta recently suggested that a better solution is to create emacs-filesystem and xemacs-filesystem sub-packages which own the /usr/share/site-{lisp|package} directories. This then allows packages to drop Elisp files into the (X)Emacs tree without pulling in (X)Emacs as dependencies. This has now been done.

Therefore I have updated the Emacs packaging guidelines to reflect this change. Please see the updated draft here:

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

I'd like FPC to consider this as a update to the Guidelines.


It appears that the draft started as a copy of the current guidelines, so the complete diff is visible as:
https://fedoraproject.org/w/index.php?title=PackagingDrafts%2FEmacs&diff=225266&oldid=225229

Some comments:

I believe this revision is useful in general, because in the past we've ended up with folks packaging simple .el files (say, the ones that provide simple syntax highlighting or an editing mode for a language or config file) as documentation because they don't want to deal with subpackages and all of the mess of actually packaging for emacs.

Tying into that, is there no way to simplify things a bit? I think the revised guidelines are way too long. Perhaps split the two cases into separate documents, so that folks who just care about case 2 can have something simple to read.

Unrelated, I guess, but if we're going to revise the Emacs guidelines.... I've always thought that naming the source packages as "emacs-common-foo" is daft. Why not just "emacs-foo"?

Replying to [comment:1 tibbs]:

It appears that the draft started as a copy of the current guidelines, so the complete diff is visible as:
https://fedoraproject.org/w/index.php?title=PackagingDrafts%2FEmacs&diff=225266&oldid=225229

Thanks, yes, I should've mentioned that.

Some comments:

I believe this revision is useful in general, because in the past we've ended up with folks packaging simple .el files (say, the ones that provide simple syntax highlighting or an editing mode for a language or config file) as documentation because they don't want to deal with subpackages and all of the mess of actually packaging for emacs.

OK. [Sidenote: if you can point me to packages where the emacs support has been packaged as docs, I'll get those fixed up - they shouldn't have passed review IMO].

Tying into that, is there no way to simplify things a bit? I think the revised guidelines are way too long. Perhaps split the two cases into separate documents, so that folks who just care about case 2 can have something simple to read.

The guidelines aren't that long if you disregard all the explanation stuff and only look at the executive summary. But, yes, they could be split up into two documents, with quite a lot of duplication between them, and the increase in maintenance cost of the two docs that goes with it. Am happy to do that though, if there's consensus in that direction.

Unrelated, I guess, but if we're going to revise the Emacs guidelines.... I've always thought that naming the source packages as "emacs-common-foo" is daft. Why not just "emacs-foo"?

Ugh. I agree, as it goes, but this was thrashed out a long time ago. Please see here, and the links therein:

http://www.redhat.com/archives/fedora-packaging/2007-May/msg00102.html

Note that emacs-common-foo is the package name for when a package builds for both GNU Emacs and Xemacs. Other alternatives were emacsen-foo, which I liked better. The point is, there's a need to distinguish packages which build for Emacs only, and those with build for both XEmacs and Emacs. "emacs" is an overloaded term, really, referring to GNu Emacs, and the family of Emacs editors.

[Sidenote: if you can point me to packages where the emacs support has been packaged as docs,
I'll get those fixed up - they shouldn't have passed review IMO].

Something like repoquery --whatprovides '/doc/.el' should give a hint.

I disagree strongly with your statement; you can package pretty much what you like as documentation, and the emacs guidelines are annoying enough that I wouldn't force them on someone who just wants to package something that happens to ship a .el file. Including as %doc is certainly better than not including them at all. And indeed I've suggested it a couple of times during package reviews.

I disagree that there is a general need at the srpm level to distinguish between packages that include for emacs only and those that package for multiple emacs variants, but it's probably not worth bothering with that at this point and I don't want to derail this needed guideline revision.

Replying to [comment:3 tibbs]:

[Sidenote: if you can point me to packages where the emacs support has been packaged as docs,
I'll get those fixed up - they shouldn't have passed review IMO].

Something like repoquery --whatprovides '/doc/.el' should give a hint.

I disagree strongly with your statement; you can package pretty much what you like as documentation, and the emacs guidelines are annoying enough that I wouldn't force them on someone who just wants to package something that happens to ship a .el file. Including as %doc is certainly better than not including them at all. And indeed I've suggested it a couple of times during package reviews.

I guess we'll have to agree to disagree here; in general I think it's bad form to not comply with a packaging guideline just because it seems inconvenient though. There's little point in having them if they're considered optional.

I do agree though that the Emacs packaging guidelines are a bit complicated. They're complicated by the existence of GNU Emacs and XEmacs, at the end of the day. However, we could drastically simplify them and avoid all need for the various sub-packages if we decided that ALL (X)Emacs add-ons need only Require (x)emacs-filesystem and not (x)emacs(bin). Then the need for separate sub-packages (the existance of which is motivated by the requirement not to pull in Emacs and XEmacs when an add-on is installed) goes away. The downside would be that a user might install emacs-auctex and be surprised to find that Emacs isn't installed on the system.

I disagree that there is a general need at the srpm level to distinguish between packages that include for emacs only and those that package for multiple emacs variants, but it's probably not worth bothering with that at this point and I don't want to derail this needed guideline revision.

That's not the reason for the emacs-common-foo naming though. This is the motivation: where a package foo is an add-on for both variants of emacs, a user might reasonably want to install only the package for Emacs, or only the package for Xemacs, and he doesn't want to drag in the other variant of emacs and its dependency chain. So that means we need subpackages emacs-foo and xemacs-foo. But we don't want one to require the other. So we need the main package to be called something else (and contain files needed by both those subpackages). It's nothing to do with srpm level distinction.

You are welcome to point out the guideline that is broken. However, if there's any guideline that says that it is not permitted to package an emacs lisp file as documentation, I think it needs to be revisited. I don't think there is one, however.

I am strongly in favor of anything that simplifies the situation for packagers. The only downside I can see is the same one you found, but then personally I'd be willing to live with that.

That's not the reason for the emacs-common-foo naming though.

I believe you missed my point entirely. I am speaking only of the name of the source rpm. Obviously we'd still need an emacs-common-foo binary package to be generated for the reasons you provide.

OK, following Tibbs suggestion, I have now split the guidelines up into two sections, one for each Case. Hopefully this adds some clarity. We could go further and split them out into their own pages, but that's probably easier done at the point they're made official guidelines.

Approved with some minor changes, already committed to the draft text.

(+1:8, 0:0, -1:0)

Announce text:

The Emacs packaging guidelines were updated to handle cases where a package's principal functionality does not require (X)Emacs, but the package also includes some auxiliary Elisp files to provide support for the package in (X)Emacs.

Metadata Update from @jgu:
- Issue assigned to spot

4 years ago

Login to comment on this ticket.

Metadata