bug#58073: 29.0.50; Uninstalled emacs sends startup messages to stderr

[Jonas Bernoulli <jonas@bernoul.li>]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Jonas Bernoulli <jonas@bernoul.li>
>> Cc: 58073@debbugs.gnu.org
>> Date: Mon, 03 Oct 2022 18:03:50 +0200
>> 
>>   cat
>>   #!/bin/sh
>>   unset EMACSLOADPATH
>>   exec -a "emacs" "/home/jonas/src/emacs/emacs/src/emacs" "$@"
>> 
>> *appears* to work as intended (by me), but in actuality it uses the
>> libraries from where the package is installed, *not* from the source
>> repository.  I didn't inspect closely enough before to notice this.
>> Also, the name of the wrapper script does not actually matter.  (Use
>> of --dump-file doesn't help.)
>
> Sorry, I don't understand: you installed Emacs _and_ invoke it from
> the source tree?  Why would you do that?

It's more complicated like that but let's say: if I hack on an Emacs
package, then I use Emacs from source, since I might hack to look at
the git history of an Emacs function I use in package; but if what I
do has nothing to do with Emacs, then I use the installed Emacs.

>> Of course that doesn't work if Emacs hasn't actually been installed.
>> 
>> For completeness sake I should mention that I have once more confirmed
>> that using a symlink works (the libraries from the repo are used), but
>> an alias does not work (the files from the installation are used).
>> 
>> > Please close, and sorry for the noise.
>> 
>> No need to reopen, as far as I am concerned, but I thought it was
>> worth mentioning this here.
>
> Now I'm confused: is the problem solved or isn't it?

I no longer need to use a wrapper to unset EMACSLOADPATH, because I now
unset that variable in a file that is being sourced not only by my login
shell but also by my display manager.  I can now launch emacs from a
program launcher that does not inherit the environment from a shell but
from the display manager.

(I had to switch display managers to accomplish that.  Previously I used
Gdm3 but that has fully embraced systemd and wayland by now and does not
source any of the files (such as ~/.xsession) that could traditionally
be used to set variable for all of an X11 session.

So after the switch to another display manager, I can now use a plain
old symlink again, and that works perfectly; the elisp libraries from
the repository are being used, when I launch the emacs binary that is
located inside emacs.git through a symlink.

Before I switched away from Gdm3, I had to use a wrapper script, but as
we found out that does not actually work.  For some reason that ends up
using the elisp libraries from where "make install" put them.  Or if
that has never been run, then emacs fails because it cannot find the
libraries where it (IMO falsely) expects to find them.  The same happens
when using a shell alias.

The question now is whether *you* consider this a bug worth fixing.
I would say it is, but I won't insist on it.

I hope that is a bit clearer now.