unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Leo Famulari <leo@famulari.name>
To: Xinglu Chen <public@yoctocell.xyz>
Cc: "Christopher Baines via Development of GNU Guix and the GNU
	System distribution." <guix-devel@gnu.org>,
	Sarah Morgensen <iskarian@mgsn.dev>
Subject: Re: Can we find a better idiom for unversioned packages?
Date: Fri, 3 Sep 2021 12:35:21 -0400	[thread overview]
Message-ID: <YTJOycpTs2RpPXZ0@jasmine.lan> (raw)
In-Reply-To: <87o899iqpp.fsf@yoctocell.xyz>

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


  reply	other threads:[~2021-09-03 16:35 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-31 19:57 Can we find a better idiom for unversioned packages? Sarah Morgensen
2021-08-31 21:20 ` Maxime Devos
2021-09-01 12:11   ` Xinglu Chen
2021-09-01 16:29     ` Maxime Devos
2021-09-01 13:33   ` Liliana Marie Prikler
2021-09-01 16:39     ` Maxime Devos
2021-09-01 18:34       ` Liliana Marie Prikler
2021-09-02 14:09         ` Maxime Devos
2021-09-02 14:20           ` Liliana Marie Prikler
2021-09-02 14:34             ` Maxime Devos
2021-09-01 19:48       ` Jonathan McHugh
2021-09-01 21:47         ` Liliana Marie Prikler
2021-09-02 13:32           ` Maxime Devos
2021-09-02  7:53         ` Jonathan McHugh
2021-09-02  9:25           ` Liliana Marie Prikler
2021-09-01 10:55 ` Xinglu Chen
2021-09-01 15:37   ` Leo Famulari
2021-09-01 16:50     ` Xinglu Chen
2021-09-02 16:51       ` Leo Famulari
2021-09-02 17:29         ` Leo Famulari
2021-09-03 16:11           ` Xinglu Chen
2021-09-03 16:35             ` Leo Famulari [this message]
2021-09-03 16:57               ` Leo Famulari
2021-09-03 20:03               ` Xinglu Chen
2021-09-04 21:00                 ` Leo Famulari
2021-09-08 21:15       ` Ludovic Courtès
2021-09-02 17:08 ` Leo Famulari
2021-09-08 21:28 ` Ludovic Courtès
2021-09-08 22:21 ` Jonathan McHugh
2021-09-08 22:38   ` Leo Famulari
  -- strict thread matches above, loose matches on Subject: below --
2021-09-03  5:51 Sarah Morgensen
2021-09-03 21:14 Sarah Morgensen
2021-09-03 22:11 ` Liliana Marie Prikler
2021-09-04 12:32   ` Taylan Kammer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YTJOycpTs2RpPXZ0@jasmine.lan \
    --to=leo@famulari.name \
    --cc=guix-devel@gnu.org \
    --cc=iskarian@mgsn.dev \
    --cc=public@yoctocell.xyz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).