Re: feature/package+vc 04c4c578c7 3/4: Allow for packages to be installed directly from VCS

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > I have pushed a commit to feature/package+vc that will use the release
  > revision (if it is known) when `package-vc-install' is invoked with a
  > prefix argument.

It is good to offer both options.  However, there may be a bug in this
way of doing it.

The words "the release revision" are somewhat terse and I am not
entirely sure what they mean.  My guess is they mean "the revision in
the upstream repo that corresponds to the released code in ELPA."  Is
that correct?

In the usual case, the released code in ELPA does correspond to some
revision in the upstream repo.  Therefore, assuming the release
revision "is known", this implementation will find the right code.

However, in unusual cases the code in ELPA includes changes that did
not come from the upstream repo, and may not be present there.  This
feature needs to DTRT in those cases too.

To check out the latest revision in the upstream repo is certainly wrong,
and it could cause serious confusion.  The command should never do
that, not even as a fallback.

What other behavior would be a better fallback?
What is TRT in these cases?

I see two reasonable possibilities:

1. To signal an error and do nothing.

2. To check out the current release version from the ELPA repo (NOT
the upstream repo).

I think #2 is better, but #1 at least avoids confusion.

In what situations is the release revision not known?
We should think about what is TRT in those cases too.
First, what cases are they?


-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)