bug#71356: use-package doesn't load org from elpa

[Eli Zaretskii <eliz@gnu.org>]

> From: Philip Kaludercic <philipk@posteo.net>
> Cc: paaguti@gmail.com,  acorallo@gnu.org,  71356@debbugs.gnu.org
> Date: Mon, 10 Jun 2024 06:02:08 +0000
> 
> >> IIUC the feature would be that if a use-package form has a
> >> 
> >>      :pin gnu
> >> 
> >> argument, then this is an indication that we want to install the package
> >> from GNU ELPA, disregarding the fact that Emacs already has a built-in
> >> version of the same package.  Sort of a package-local version of
> >> `package-install-upgrade-built-in'.
> >
> > I'm not sure.  People tend to copy/paste recipes from the Internet
> > without really understanding what they do.  I think a simple :pin
> > should not be sufficient, we need some specialized keyword (in
> > addition to supporting package-install-upgrade-built-in).
> 
> To me :pin would make perfect sense, as it explicitly expresses what
> archive we want to follow for package upgrades.

Bitter experience should have taught us that what makes perfect sense
to us does not necessarily make such perfect sense to others.  Which
is why we don't like to make incompatible changes in behavior even
though the new behavior sounds like a definite TRT to us.

Let me remind you that similar arguments were voiced to make
package-install-upgrade-built-in be the default.  We didn't.

So I'd like us to trod cautiously here, abiding by the same logic as
package-install-upgrade-built-in.  If nothing else, that's consistent
with other methods of upgrading built-in packages.

> >> I am not familiar with the use-package code, but it seems like we could
> >> implement this generally in package-install, by checking
> >> `package-pinned-packages'.
> >
> > I would prefer not to introduce another indication of whether built-in
> > packages should or should not be upgraded.  If we do, we will next
> > need to decide which one "wins" when they contradict each other.
> 
> One idea would be that use-package would check :pin and then
> conditionally bind `package-install-upgrade-built-in' when invoking
> `package-install'.  That being said, I am not a fan of the user option
> any way, and wouldn't mind if we came up with a cleaner solution.

Cleaner that package-install-upgrade-built-in?  Why is that "unclean"?
Given that users may or may not want the built-in packages to be
updated en-masse with their usual updates, a user option lets everyone
have what they prefer, so it's the cleanest possible solution, IMO.