> > > > > 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.
signature.asc
Description: This is a digitally signed message part
