Packaging emacs modes: EL/F compatibility

[Michel Salim]

When packaging a package that contains Emacs mode files, should the
Emacs subpackage require emacs(bin) or emacs? emacs(bin) seems to be
commonly used, but this is not provided by RedHat/Fedora Emacs
packages until version 22; RHEL 5.2 is still on 21.4 and thus EPEL
packages would have to be specially handled.

So the question is: is it better to use an %ifdef for non-Fedora
releases or to just depend on emacs?

Thanks,

[Michel Salim]

On Fri, Oct 10, 2008 at 9:02 AM, Michel Salim  wrote:
> When packaging a package that contains Emacs mode files, should the
> Emacs subpackage require emacs(bin) or emacs? emacs(bin) seems to be
> commonly used, but this is not provided by RedHat/Fedora Emacs
> packages until version 22; RHEL 5.2 is still on 21.4 and thus EPEL
> packages would have to be specially handled.

A related question: why emacs(bin) ? xemacs provides xemacs(bin) too
so the question applies there. We don't ever plan for the binary to be
provided in a subpackage, do we?

Thanks,

[Ville Skyttä]

On Friday 10 October 2008, Michel Salim wrote:
> On Fri, Oct 10, 2008 at 9:02 AM, Michel Salim

wrote:
> > When packaging a package that contains Emacs mode files, should the
> > Emacs subpackage require emacs(bin) or emacs?

Depends.  In the vast majority of cases "emacs(bin)", but it the elisp stuff 
specifically requires a full featured/X11 enabled emacs and does not work 
with emacs-nox, then "emacs" would be appropriate.  Ditto for xemacs.
> > emacs(bin) seems to be 
> > commonly used, but this is not provided by RedHat/Fedora Emacs
> > packages until version 22; RHEL 5.2 is still on 21.4 and thus EPEL
> > packages would have to be specially handled.
>
> A related question: why emacs(bin) ?

Most elisp packages work fine with either emacs or emacs-nox installed.  
emacs(bin) is provided by both of them, and requiring it in lisp packages 
where appropriate is helpful so that the full featured (and much more 
dependency heavy) emacs package is not pulled in in setups that are fine 
with -nox, such as headless servers etc.
> xemacs provides xemacs(bin) too 
> so the question applies there. We don't ever plan for the binary to be
> provided in a subpackage, do we?

We already have it kind of that way for both emacs and xemacs.  The emacs, 
emacs-nox, xemacs, and xemacs-nox packages don't contain much more than just 
the respective executable.

[Michel Salim]

On Fri, Oct 10, 2008 at 1:12 PM, Ville Skyttä  wrote:
> > A related question: why emacs(bin) ?
>
> Most elisp packages work fine with either emacs or emacs-nox installed.
> emacs(bin) is provided by both of them, and requiring it in lisp packages
> where appropriate is helpful so that the full featured (and much more
> dependency heavy) emacs package is not pulled in in setups that are fine
> with -nox, such as headless servers etc.

Unfortunately RHEL's emacs / emacs-nox do not seem to provide
emacs(bin), so in that case, since RPM does not allow for either-or
dependencies, what would the best solution be?

1. Requires: emacs and disenfranchise emacs-nox users
2. Requires: /usr/bin/emacs and draw the ire of yum users having to
download filelists.

Thanks,

[Stephen John Smoogen]

On Fri, Oct 10, 2008 at 5:33 PM, Michel Salim  wrote:
> On Fri, Oct 10, 2008 at 1:12 PM, Ville Skyttä  wrote:
> > > A related question: why emacs(bin) ?
> >
> > Most elisp packages work fine with either emacs or emacs-nox installed.
> > emacs(bin) is provided by both of them, and requiring it in lisp packages
> > where appropriate is helpful so that the full featured (and much more
> > dependency heavy) emacs package is not pulled in in setups that are fine
> > with -nox, such as headless servers etc.
>
> Unfortunately RHEL's emacs / emacs-nox do not seem to provide
> emacs(bin), so in that case, since RPM does not allow for either-or
> dependencies, what would the best solution be?
> Requires: emacs and disenfranchise emacs-nox users
> Requires: /usr/bin/emacs and draw the ire of yum users having to
>
> download filelists.

3. Get RHEL to fix its packages? 4.x/5.x are still under support and
could get updates.

[Patrice Dumas]

On Fri, Oct 10, 2008 at 07:33:45PM -0400, Michel Salim wrote:
> On Fri, Oct 10, 2008 at 1:12 PM, Ville Skyttä  wrote:
>
> Unfortunately RHEL's emacs / emacs-nox do not seem to provide
> emacs(bin), so in that case, since RPM does not allow for either-or
> dependencies, what would the best solution be?
> Requires: emacs and disenfranchise emacs-nox users
> Requires: /usr/bin/emacs and draw the ire of yum users having to
>
> download filelists.

/usr/bin/ is always downloaded.

--
Pat

[Michel Salim]

On Fri, Oct 10, 2008 at 7:57 PM, Patrice Dumas  wrote:
> On Fri, Oct 10, 2008 at 07:33:45PM -0400, Michel Salim wrote:
> > On Fri, Oct 10, 2008 at 1:12 PM, Ville Skyttä  wrote:
> >
> > Unfortunately RHEL's emacs / emacs-nox do not seem to provide
> > emacs(bin), so in that case, since RPM does not allow for either-or
> > dependencies, what would the best solution be?
> > Requires: emacs and disenfranchise emacs-nox users
> > Requires: /usr/bin/emacs and draw the ire of yum users having to
> >
> > download filelists.
>
> /usr/bin/ is always downloaded.

Ah, so one gets that for free? (the guideline should really mention
that). I'll wait for an official word on the bug report,
https://bugzilla.redhat.com/show_bug.cgi?id=466580

but if nothing comes up in the next few days, I might just do that.

Thanks,

[Toshio Kuratomi]

Michel Salim wrote:
> On Fri, Oct 10, 2008 at 7:57 PM, Patrice Dumas  wrote:
> > On Fri, Oct 10, 2008 at 07:33:45PM -0400, Michel Salim wrote:
> > > On Fri, Oct 10, 2008 at 1:12 PM, Ville Skyttä  wrote:
> > >
> > > Unfortunately RHEL's emacs / emacs-nox do not seem to provide
> > > emacs(bin), so in that case, since RPM does not allow for either-or
> > > dependencies, what would the best solution be?
> > > Requires: emacs and disenfranchise emacs-nox users
> > > Requires: /usr/bin/emacs and draw the ire of yum users having to
> > >
> > > download filelists.
> >
> > /usr/bin/ is always downloaded.
>
> Ah, so one gets that for free? (the guideline should really mention
> that). I'll wait for an official word on the bug report,
> https://bugzilla.redhat.com/show_bug.cgi?id=466580

The Guideline does mention that:
"""
- SHOULD: If the package has file dependencies outside of /etc, /bin,
/sbin, /usr/bin, or /usr/sbin consider requiring the package which
provides the file instead of the file itself.
"""

The full Guideline[1]_ (linked from the above) repeats that information
and also tells why those directories are okay.

.. _[1]: https://fedoraproject.org/wiki/Packaging/Guidelines#FileDeps

-Toshio