Re: Finding the dump (redux)

[Ali Bahrami <ali_gnu2@emvision.com>]

On 4/19/21 11:19 AM, Eli Zaretskii wrote:
> 
> I don't understand: if the user re-dumps Emacs, then under your
> suggestion the user will have the same problem with Emacs locating the
> pdumper file as we have today.  So what did we fix, exactly?
> 

Yeah, it's gotten a bit sprawling, so let's try to recap.

The guy who re-dumps emacs doesn't have a problem, and
I'm not trying to do anything for him other than to not
break what he does. Most of this conversation has been your
pointing out ways in which I might be causing a problem for
that guy, and my trying to provide good answers for how
we might avoid that. So we've fixed nothing for him, but
importantly, have also broken exactly nothing.

I started this by noting that a symlink pointing at an
emacs binary, fails to find it's pdump file. That's
what I want to fix. And, we've now got 3 offers on the
table for how we might do that:

     - Use the basename from the realpath() when searching
       PATH_EXEC. My first patch looked at both the given
       and realpath() versions, but I now think just using
       the realpath() one is the better, simpler, answer.

     - Use the fingerprint for the PATH_EXEC pdmp files, rather
       than the executable name.

     - Put the data in the executable, but avoiding
       the unexec pitfalls, which are well known.

In this, I represent the many people who run emacs from
prebuilt packages, and who will never dump anything, or
even probably ever know what dumping is. What they do want,
is to be able to run emacs via an arbitrary symlink name,
and have it just work. Any of the above options fixes that.

And in particular, we put such a symlink in /usr/bin,
to provide a generic 'emacs' to users who don't care
about the UI variants. pdump has broken that use, and
I want to fix it, without dropping data files in /usr/bin.

- Ali