> > > > > 2. We cannot get at the source location for the definition of
> > > > > 'commit' or 'revision'.  This would be useful for updating
> > > > > these
> > > > > packages with `guix refresh -u`.  There is a proposed patch [0]
> > > > > to
> > > > > work around this, but it *is* a workaround.
> > > Other versioning idioms would also be workarounds, wouldn't they?
> > > 
> > > > > 3. Packages inheriting from it lose the definitions.  For
> > > > > actual
> > > > > fields, we have e.g. `(package-version this-package)`, but we
> > > > > have
> > > > > no equivalent for these.
> > > What purpose would extracting those serve however? 
> > 
> > Not losing the revision is useful for things like 
> > <https://issues.guix.gnu.org/50072>;, to be able to determine the old
> > revision.  (That's not about inheriting packages though.)

> Isn't that addressed by addressing the second point, though?  Like, if
> you know the source location of the revision, you can read it back to
> get the value itself (or possibly even access it as-is), no?

Indeed!  The patch [0] addresses the second point.  With that patch,
the proposed <extension-version> isn't required.  But also: some people
(at least Sarah?) consider [0] a work-around, and if guix used something
like <extended-version>, [0] wouldn't be necessary.

It doesn't really matter to me what we'll end up using in guix
in the long term, though in the short term, I would like something
like [0] to be merged, as it is used by the (not-yet submitted, needs some
cleanup, testing & rebasing) minetest updater, and it makes
<https://issues.guix.gnu.org/50072> work in more cases.

[0]: <https://issues.guix.gnu.org/50072>

Greetings,
Maxime.