Re: Can we find a better idiom for unversioned packages?

[Leo Famulari]

On Fri, Sep 03, 2021 at 06:11:46PM +0200, Xinglu Chen wrote:
> The date does give an idea of how old the version is, compare that to a
> random string of 7 characters.  If a user wants to know the exact
> commit, they can always just run ‘guix edit PACKAGE’ and check the
> ‘commit’ field in the source of the package.

That's true.

However, it's not easy to figure out which revision of guix.git produced
a package that is installed in a profile.

The transformation from package definition to built package is lossy.
You cannot take a built package and ask Guix "which guix.git commit was
used for this?"

So, if I have a package foo-0.0.0-1-2021-12-31 in my profile, it's
impossible to reliably trace that back to the correct Guix package
definition and then discover what upstream source code it was built
with. [0] On the other hand, if the package's version includes the Git
commit, it's trivial.

So, I think we each have different needs that we want satisfied:

1) To know how old the package's source code is
2) To know what source code a built package is based on

The second item is something I do often, and I think a lot of Guix
developers do it too. And in general, it's imporant for store paths to
include meaningful "version" information; a date is not meaningful in
this sense. So let's be careful not to lose that ability by removing
commit IDs from the package versions.

We can satisfy both of these by adding the date to the version string,
although we should be careful not to risk exceeding Linux's shebang
length limit (127), which sometimes will crop up if packages provide
shebang-able interpreters. The store path needs to be short enough that
the "bin/foo" part does not make the absolute path exceed 127
characters. This is something that was addressed while designing the
current versioning for VCS snapshots.

I'm still skeptical of the utility of adding a date, given the lack of
useful time information conveyed by Git, but if people really want it
and it can be made to work, then we should go ahead.

[0] Complications arise when a package origin includes patches or
snippets, but anyways...