Re: Reconsider defaults for use-package-vc-prefer-newest

[Suhail Singh <suhailsingh247@gmail.com>]

Philip Kaludercic <philipk@posteo.net> writes:

>> Which are the two packages being considered?
>
> IIRC the local package you have installed, the package on NonGNU ELPA,
> the package on MELPA Stable and the package on MELPA Unstable.

Since MELPA Unstable adds time-based versioning which is incompatible
with NonGNU and MELPA Stable, it can simply be ignored.  I.e., *only*
when NonGNU (or much less likely, but for completeness GNU) ELPA and
MELPA Stable version numbers match do we care about checking to verify
if the commits match as well.

>> From my perspective, the following is the desired behaviour: whenever
>> package.el has evidence that the same purported package version is being
>> served via different commits in the various remote archives (that the
>> user has enabled) the user is made aware.  If the package versions
>> aren't the same, then no "COMMIT MISMATCH" should be shown.
>
> Yeah, that was my intention as well.

Hm I didn't see the check to ensure that the package versions were
identical in the last patch, but perhaps that was happening implicitly
somehow.

>> I.e., the situation of interest is when versions match, but commits
>> don't.  If it helps, "NON-UNIQUE COMMIT" might be more accurate, but I
>> don't have a strong opinion on the wording.
>
> NON-UNIQUE COMMIT seems more vague to me?

Yeah, I don't have a strong opinion on how we phrase it as long as the
intended intent is "the version number of this package matches the
version number available from another source, however the commits don't
match".

> And VC packages seem like a bit of an headache in this case, as

Yeah, if you want to exclude VC packages I have no objection.
Presumably if someone is using :vc checkout they are already paying
attention to the commits.

> Right, I'll try to test this myself before sending you more patches ^^

All good; appreciate your time on this :)

>> Thanks for sharing the reference, but why is this not in the default
>> branch (which is the only one linked from <https://elpa.gnu.org/>) to
>> begin with?  Alternatively, if the elpa-admin variant is considered the
>> canonical version, why doesn't the link from <https://elpa.gnu.org/>
>> point to
>> <https://git.savannah.gnu.org/cgit/emacs/elpa.git/plain/README?h=elpa-admin>
>> instead?
>
> No reason really, I'll try to update it soon.

Thank you.

-- 
Suhail