We don't want to change what :pin means, IMHO we need it to obey `package-install-upgrade-built-in`.
That wouldn't be incompatible, right?

So the sketch that actually loads org from elpa would be

(let ((package-install-upgrade-built-in t))
  (use-package org
    :ensure t :pin gnu))

whereas

  (use-package org
    :ensure t :pin gnu)

would keep the original org packaged with emacs (called with emacs -Q)

Best, /PA


On Mon, 10 Jun 2024 at 18:12, Eli Zaretskii <eliz@gnu.org> wrote:
> From: Philip Kaludercic <philipk@posteo.net>
> Cc: Andrea Corallo <acorallo@gnu.org>,  paaguti@gmail.com,
>   71356@debbugs.gnu.org
> Date: Mon, 10 Jun 2024 15:40:58 +0000
>
> >> > To me :pin would make perfect sense, as it explicitly expresses what
> >> > archive we want to follow for package upgrades.
> >>
> >> +1, also use-package interface is very declarative and I'm not sure
> >> having it influenced by a dynamic var would match user expected
> >> behavior.
> >
> > If you prefer, we could add a new :foo keyword to mean this.  But
> > unconditionally changing what :pin means in these cases is out of the
> > question.
>
> We wouldn't change what :pin means directly, but just have
> package-install respect `package-pinned-packages'.

How is that different?  It's an incompatible change of behavior, and I
cannot agree to that, sorry.


--
Fragen sind nicht da, um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run a leader-deposed hook here, but we can't yet