unofficial mirror of bug-guix@gnu.org 
 help / color / mirror / code / Atom feed
From: Leo Prikler <leo.prikler@student.tugraz.at>
To: Maxim Cournoyer <maxim.cournoyer@gmail.com>
Cc: 47458@debbugs.gnu.org
Subject: bug#47458: Terrible UX upgrading Emacs in Guix
Date: Sun, 04 Apr 2021 09:49:31 +0200	[thread overview]
Message-ID: <0491bf7a885f44dbf62e2ca3b21fb5671daed5ec.camel@student.tugraz.at> (raw)
In-Reply-To: <87wntipsz0.fsf_-_@gmail.com>

Hi Maxim!

Am Sonntag, den 04.04.2021, 00:35 -0400 schrieb Maxim Cournoyer:
> Hi Leo!
> 
> Leo Prikler <leo.prikler@student.tugraz.at> writes:
> 
> > With this, the search path specification of EMACSLOADPATH does no
> > longer
> > depend on the version of Emacs, which should make upgrading major
> > versions
> > less painful.  See also:
> > - <https://bugs.gnu.org/43627>
> > - <https://bugs.gnu.org/47458>
> > 
> > * gnu/packages/emacs.scm (emacs)[#:phases]: Add ‘wrap-load-path’.
> > [native-search-path]<EMACSLOADPATH>: Do not search for builtin
> > libraries.
> > (emacs-next)[native-search-path]: Inherit from emacs.
> > ---
> >  gnu/packages/emacs.scm | 31 ++++++++++++++++---------------
> >  1 file changed, 16 insertions(+), 15 deletions(-)
> > 
> > diff --git a/gnu/packages/emacs.scm b/gnu/packages/emacs.scm
> > index 7447cfe33a..e12c489f8d 100644
> > --- a/gnu/packages/emacs.scm
> > +++ b/gnu/packages/emacs.scm
> > @@ -201,6 +201,20 @@
> >                  (car (find-files "bin" "^emacs-([0-9]+\\.)+[0-
> > 9]+$"))
> >                  "bin/emacs")
> >                 #t)))
> > +         (add-after 'strip-double-wrap 'wrap-load-path
> > +           (lambda* (#:key outputs #:allow-other-keys)
> > +             (let* ((out (assoc-ref outputs "out"))
> > +                    (lisp-dirs (find-files (string-append out
> > "/share/emacs")
> > +                                           "^lisp$"
> > +                                           #:directories? #t)))
> > +               (for-each
> > +                (lambda (prog)
> > +                  (wrap-program prog
> > +                    `("EMACSLOADPATH" suffix ,lisp-dirs)))
> > +                (find-files (string-append out "/bin")
> > +                            ;; versioned and unversioned emacs
> > binaries
> > +                            "^emacs(-[0-9]+(\\.[0-9]+)*)?$"))
> > +               #t)))
> 
> Shouldn't we wrap all the binaries to be on the safe side?  Things
> such
> as emacsclient probably ought to have EMACSLOADPATH set correctly,
> no?
The remaining binaries are
- emacsclient, which inherits its EMACSLOADPATH from the server it
connects to
- ctags, ebrowse and etags, which are helper binaries, that don't seem
to rely on EMACSLOADPATH at all.  (Or is there an indicator, that they
do?)
- .-real binaries, that should only be wrapped once.
We could relax the regex to include the upper two, but I don't think
it's necessary to do so.

> >           (add-before 'reset-gzip-timestamps 'make-compressed-
> > files-writable
> >             ;; The 'reset-gzip-timestamps phase will throw a
> > permission error
> >             ;; if gzip files aren't writable then.  This phase is
> > needed when
> > @@ -255,9 +269,7 @@
> >      (native-search-paths
> >       (list (search-path-specification
> >              (variable "EMACSLOADPATH")
> > -            ;; The versioned entry is for the Emacs' builtin
> > libraries.
> > -            (files (list "share/emacs/site-lisp"
> > -                         (string-append "share/emacs/" version
> > "/lisp"))))
> > +            (files '("share/emacs/site-lisp")))
> >             (search-path-specification
> >              (variable "INFOPATH")
> >              (files '("share/info")))))
> > @@ -294,18 +306,7 @@ languages.")
> >             "0igjm9kwiswn2dpiy2k9xikbdfc7njs07ry48fqz70anljj8y7y3")
> > )))
> >        (native-inputs
> >         `(("autoconf" ,autoconf)
> > -         ,@(package-native-inputs emacs)))
> > -      (native-search-paths
> > -       (list (search-path-specification
> > -              (variable "EMACSLOADPATH")
> > -              ;; The versioned entry is for the Emacs' builtin
> > libraries.
> > -              (files (list "share/emacs/site-lisp"
> > -                           (string-append "share/emacs/"
> > -                                          (version-
> > major+minor+point version)
> > -                                          "/lisp"))))
> > -             (search-path-specification
> > -              (variable "INFOPATH")
> > -              (files '("share/info"))))))))
> > +         ,@(package-native-inputs emacs))))))
> >  
> >  (define-public emacs-next-pgtk
> >    (let ((commit "ae18c8ec4f0ef37c8c9cda473770ff47e41291e2")
> 
> This makes sense, and can make it to master rather than core-updates,
> which is neat.
I'd like to avoid pushing this to master just yet, because we also have
changes in the Emacs build system to discuss and I don't want to cause
an "Emacs world" rebuild twice in a row.  That said, I'm including this
patch in wip-emacs with the plan to push to master or staging once
everything there is resolved.

Regards,
Leo





  reply	other threads:[~2021-04-04  7:50 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-29  2:02 bug#47458: Terrible UX upgrading Emacs in Guix Mark H Weaver
2021-03-29  8:07 ` Leo Prikler
2021-03-29  8:24   ` Maxime Devos
2021-03-29  8:43     ` Leo Prikler
     [not found] ` <20210330184101.7643-1-leo.prikler@student.tugraz.at>
2021-04-04  4:35   ` Maxim Cournoyer
2021-04-04  7:49     ` Leo Prikler [this message]
2021-04-06 12:09       ` Maxim Cournoyer
2021-04-06 15:49         ` Leo Prikler
2021-04-07 19:46           ` Maxim Cournoyer
2021-05-20 13:24             ` Maxim Cournoyer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=0491bf7a885f44dbf62e2ca3b21fb5671daed5ec.camel@student.tugraz.at \
    --to=leo.prikler@student.tugraz.at \
    --cc=47458@debbugs.gnu.org \
    --cc=maxim.cournoyer@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).