On Fri, Sep 03 2021, Leo Famulari wrote:

> 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.

‘guix describe’ would show the commit of the guix.git repo used,
wouldn’t it?

> 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.

Good point, I don’t really have a good solution to that.

> 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 didn’t know Linux had this weird(?) restriction, but yeah, it will be
something to think about.

> 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.

If the date is not part of the version string, I think that there should
at least be a comment saying the the date of the commit, just to let
other people quickly see how old the version is.