[Fedora-packaging] Packaging guidelines for Emacsen add-on packages

[Jonathan Underwood]

On 07/05/07, Ville Skyttä <ville.skytta at iki.fi> wrote:
> > Comments gladly received!
>
> Quickly reading through it, here's a couple.
>

Thanks for taking a look, Ville. I'll incoorporate your suggestions in
a couple of days, once other people have also commented. A couple of
questions though:

> 1) I think cases where install time dependencies on plain "emacs" or "xemacs"
> are desirable are very rare.  The usual problem with those is that they bind
> the add-on packages to the corresponding full featured variants, ie. ones
> built with X etc, so one can't use them with only the -nox variant installed.
> That's why I addded a virtual "xemacs(bin)" Provides to the xemacs and
> xemacs-nox packages - that'd be a better thing to have a dependency on than
> eg. "xemacs" unless the full featured GUI version is specifically required.

OK, I'll incoorporate that into the templates and make a note about it.
Can I ask though - there's no special meaning given to parentheses in
Provides: foo(bar) is there?

> The emacs packages don't have that functionality (yet?), so I think the best
> thing for them for now would be to have a dependency on emacs-common instead
> of emacs or emacs-nox.
>

Yes; I checked and both emacs and emacs-nox Require: emacs-common so
that would work.

I will open a bugzilla RFE asking for a virtual Provides: emacs(bin)
though for the future, I think that's a good idea.

> 2) At least in the XEmacs case, the dependency on xemacs(bin) should be
> versioned, like "Requires: xemacs(bin) >=
> $evr_of_xemacs_used_to_build_the_package".  The xemacs-bytecompiled *.elc
> files are in the vast majority of cases forwards compatible, but much less
> often backwards compatible.  See the xemacs-packages-base and
> xemacs-packages-extras packages for examples.  (Hm, I see those have deps on
> xemacs-common instead of xemacs(bin), will have a look.)

Yes, I could expliti#ly add mention of that. I had assumed that would
fall within a packagers general knowledge as it's not especially
significant to X#(X)Emacs. But, no harm adding it anyway, you're
right.

Thanks again for the input,
Jonathan.