bug#30994: bug#45857: 28.0.50; Not possible to set package-user-dir in early-init.el

[Eli Zaretskii <eliz@gnu.org>]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: ola.x.nilsson@axis.com,  45857@debbugs.gnu.org,  30994@debbugs.gnu.org
> Date: Thu, 14 Jan 2021 16:02:30 -0500
> 
> > I think relying on a small number of such variables is not
> > future-proof enough.  This case is a living proof: we decided
> > something 2 years ago, but changes we did since then require us now to
> > change that decision, which means we risk bumping into issues which we
> > wanted to avoid back then.  That's a general problem with kludgey
> > solutions.
> 
> Indeed.  Other than eliminate the `blink-cursor-mode` special case,
> I can't see how to make it less kludgey.

But that's still the same kludge: we will rely on the fact that there
are currently no (i.e. zero, a.k.a. "a small number") of such
variables.

> > Basically, some variables can only be usefully initialized after some
> > part(s) of startup have happened already.  One way of dealing with
> > this is to have the variables record this information (e.g., in a
> > plist of their symbol) that would allow us evaluate each variable only
> > once, at the earliest opportunity where the prerequisites are
> > fulfilled.
> 
> In theory I would agree, but:
> - We don't have any such system to record dependencies, so we'd have to
>   design and implement it.  A minimal version would simply duplicate
>   `customize-initialize-delayed` into two different options depending on
>   the stage at which we should initialize it, but that'd still be pretty
>   ad-hoc.

It isn't ad-hoc, because the stages in the startup process and their
effects are clearly defined and didn't change much for a long time.

> - The only need for this complexity is `blink-cursor-mode` and it's only
>   needed because we currently handle `blink-cursor-mode` incorrectly.
>   So, I'd rather fix the bug and avoid the complexity.

That'd probably work for another couple of years, and then break
again.  The early-init file introduction is letting a genie out of the
bottle: we don't yet know what it will eventually require, but we
already see some serious problems it causes that we need to adapt to.
I say we should get ready for the future now.  Introducing the
infrastructure I mentioned is not a big deal.

I don't want to argue further about this, so if you are still
unconvinced, so be it.