emacs: update to 27.1

Andreas Wacknitz

2020-08-16 70a91e76c6f19ec75c3596eeb7dcc6afbf4f9ea1

 components/editor/emacs/README

@@ -18,11 +18,11 @@
#
# CDDL HEADER END
#
# Copyright (c) 2008, 2013, Oracle and/or its affiliates. All rights reserved.
# Copyright (c) 2008, 2019, Oracle and/or its affiliates. All rights reserved.
#

NAME:             emacs
VERSION:          24.5
VERSION:          26.3
DESCRIPTION:      GNU Emacs editor
LICENSE:          GPLv3
BUGTRAQ:          solaris/utility/emacs
@@ -34,16 +34,42 @@
information needed to understand how this component is put together.


- We patch the following changes to the emacs sources:
- We patch the following changes into the emacs sources:

   find.patch
       The rgrep function uses the GNU-specific -path option to the
       find command. Change the default value for the find-program
       variable in grep.el to use GNU find.

       In recent releases, we find that the find-program variable
       is repeated in other autogenerated files (ldefs.boot.el,
       loaddefs.el), and that these copies must also be adjusted.
       The safest policy is to do a brute force search of the entire
       source tree for defvar of find-program, and to fix them all.

   gnutls.patch
       Add the cert bundle path for Solaris and Solaris-derived
       systems. This allows gnutls to find public keys.

- If you patch configure.ac, as we did with emacs 24.5 for jpeg6b_config.patch,
  then you need a COMPONENT_PREP_ACTION definition in the Makefile in order
  to get the configure script generated during the 'prep' phase. This must
  issue the same commands that would otherwise be generated by the emacs
  Makefile. To get those commands, comment out COMPONENT_PREP_ACTION, and do a
  'gmake clobber; gmake build', capturing the output, and then look for
  'autoconf' in the output. The COMPONENT_PREP_ACTION for jpeg6b looked like:

  # We patch the configure.ac file. Get the new configure generated during prep.
  COMPONENT_PREP_ACTION = (cd $(@D) ; aclocal -I m4; autoconf )

  It went just after the include lines, above VARIANTS


- The emacs distribution used to have a subdirectory, src/s, which
  contained per-platform header files. We would apply the following
  patches:
  patches. Please note that the contact information given in the comment
  in the first patch is no longer valid. Current information is found in
  the README file in the top level directory of this workspace:

    sol2-6.h: Enable the use of the native Solaris dldump()

@@ -83,8 +109,8 @@
         /* There have problems reported with mmap at least on Solaris 2.6
            and 2.7.  For simplicity, let's not use mmap for anything >= 2.5.

  These are both handled by default by the configure process, and in fact,
  comments from the header file appear to have been carried over. With every
  These are now both handled by default by the configure process, and in fact,
  comments from the header files appear to have been carried over. With every
  update, we must verify that these settings stick and remain enabled.

    System Malloc:
@@ -130,6 +156,46 @@
  versions are quite stable from release to release, so this isn't a large
  burden.

- By default, emacs will find and use the Image Magick image manipulation
  library. The problem with this for Solaris is that the IM library APIs
  are not committed, and change from release to release, as opposed to the
  command line interfaces which are stable. Any update to IM causes breakage
  in emacs that takes 2 builds to resolve. At the same time, IM is not central
  to emacs use, and so, we choose to explicitly disable it with the
  --without-imagemagick config option. This can be revisited if we find that
  common emacs use suffers without it, or if IM stabilizes their library APIs.

- With multiple emacs binaries, there is a need for a generic /usr/bin/emacs
  to exist, which will by default run the "best" version of emacs installed
  on the system. Older versions of Emacs for Solaris, dating back to the 
  original integration into OpenSolaris, used a shell script that contained
  this logic:

        for EXE in emacs-gtk emacs-x emacs-nox; do
                if [ -f /usr/bin/$EXE ]; then
                        exec /usr/bin/$EXE "$@"
                fi
        done

  With the update to Emacs 24.5, we have dropped that script, and /usr/bin/emacs
  is now an IPS mediated link. The admin can therefore use 'pkg set-mediator'
  to establish their preference. The mediator names are the same as those of
  the emacs binaries (emacs-gtk, emacs-x, emacs-nox). By default, the mediated
  link will give the same order as before (gtk, x, nox). The means by which
  this is achieved needs some explanation. The mediated options are by default
  sorted in the order:

      priority, version, implementation-order, implementation

  Where "implementation" is sorted lexically. Lexical sorting puts emacs-gtk
  first, which is what we want, but it puts emacs-nox ahead of emacs-x. I
  played with setting the version or implementation-order values to achieve
  the desired sorting. This works, but as these are not real Emacs versions, 
  the output from 'pkg mediator' is confusing. Instead, we set the priority 
  of emacs-gtk and emacs-x to "vendor", and leave the priority of emacs-nox
  unspecified. Hence, emacs-gtk trumps emacs-x based on lexical sorting, and
  both of them trump emacs-nox based on priority.

- In the past, we built emacs with gcc. The Makefile contained:

    # This code is built with gcc. The primary reason for this is that the
@@ -138,12 +204,33 @@
    # cost/benefit decision not to pursue it at this time
    COMPILER =      gcc

  With emacs 24.3, I removed this, and find that studio now builds
  emacs without issue. This is something that should be reverified
  with each update.
  With emacs 24.3, I removed this, and found that studio now builds
  emacs without issue.

- Remember to update REQUIRED_PACKAGES when updating to a new version,
  as dependencies can change. Instructions are on the Userland website.
  With emacs 25.2, the studio compilers on sparc produce broken behavior
  at the -xO4 optimization level.

      26552153 emacs on sparc does not wrap long line
      26558067 emacs loses mouse cursor on sparc

  This can be mitigated by changing to -xO2. However, we don't know what
  the real issue is, and therefore, do not fully know if that's sufficient.
  Therefore, we're back to using gcc.

- When updating to a new version, remember to ensure that the REQUIRED_PACKAGES
  lines in the Makefile are updated to match. Instructions can be found in the
  doc directory at the top of the userland workspace. Basically:

   % gmake REQUIRED_PACKAGES

  and then edit the Makefile to incorporate the added lines into what's
  there, and remove any no longer needed things.

- Emacs is configured to use GnuTLS 3 rather than version 2. Version 3 used
  to require gnutls-3, but has been moved to the default gnutls. The gnutls-3
  line remains during the transition period, and can be removed soon.

    REQUIRED_PACKAGES += library/gnutls-3

- We deliver the following packages:

@@ -168,9 +255,13 @@
  In turn, gnu-emacs requires at least one of the packages supplying an
  emacs binary to be installed.

- We do not ship any suid/sgid binaries for obvious security reasons.
- Emacs things we don't deliver:

  We do not install the files under /var/games/emacs. The reason for
  this is that we do not install update-game-score as setuid, and
  therefore the game files are not usable. This the same decision made
  by Debian, among others.
    x) We do not ship any suid/sgid binaries for obvious security reasons.

    x) We do not install the files under /var/games/emacs. The reason for
       this is that we do not install update-game-score as setuid, and
       therefore the game files are not usable. This the same decision made
       by Debian, among others.

    x) usr/lib/systemd/user/emacs.service: Without systemd, it's not useful.