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