From mboxrd@z Thu Jan  1 00:00:00 1970
From: Konrad Hinsen <konrad.hinsen@fastmail.net>
Subject: Re: Why reproducibility is breaking by metadata?
Date: Mon, 08 Jul 2019 09:51:33 +0200
Message-ID: <m1pnmlvu9m.fsf@ordinateur-de-catherine--konrad.home>
References: <71aab7b233f9f6df36e0248c86b5e020@disroot.org>
 <m1v9wjd3kr.fsf@ordinateur-de-catherine--konrad.home>
 <87k1cvxzga.fsf@roquette.mug.biscuolo.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Return-path: <help-guix-bounces+gcggh-help-guix=m.gmane.org@gnu.org>
Received: from eggs.gnu.org ([2001:470:142:3::10]:51178)
 by lists.gnu.org with esmtp (Exim 4.86_2)
 (envelope-from <konrad.hinsen@fastmail.net>) id 1hkOR3-0003Kt-K6
 for help-guix@gnu.org; Mon, 08 Jul 2019 03:51:42 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <konrad.hinsen@fastmail.net>) id 1hkOR2-0002oN-Kp
 for help-guix@gnu.org; Mon, 08 Jul 2019 03:51:41 -0400
Received: from wout5-smtp.messagingengine.com ([64.147.123.21]:34529)
 by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32)
 (Exim 4.71) (envelope-from <konrad.hinsen@fastmail.net>)
 id 1hkOR2-0002lD-5p
 for help-guix@gnu.org; Mon, 08 Jul 2019 03:51:40 -0400
In-Reply-To: <87k1cvxzga.fsf@roquette.mug.biscuolo.net>
List-Id: <help-guix.gnu.org>
List-Unsubscribe: <https://lists.gnu.org/mailman/options/help-guix>,
 <mailto:help-guix-request@gnu.org?subject=unsubscribe>
List-Archive: <https://lists.gnu.org/archive/html/help-guix>
List-Post: <mailto:help-guix@gnu.org>
List-Help: <mailto:help-guix-request@gnu.org?subject=help>
List-Subscribe: <https://lists.gnu.org/mailman/listinfo/help-guix>,
 <mailto:help-guix-request@gnu.org?subject=subscribe>
Errors-To: help-guix-bounces+gcggh-help-guix=m.gmane.org@gnu.org
Sender: "Help-Guix" <help-guix-bounces+gcggh-help-guix=m.gmane.org@gnu.org>
To: Giovanni Biscuolo <g@xelera.eu>, znavko@disroot.org, help-guix <help-guix@gnu.org>

Hi Giovanni,

> Just "food for thought": git-annex metadata allows users to attach
> arbitrary metadata to their annexed files, =C2=ABmetadata is stored in the
> git-annex branch, and so is automatically kept in sync with the rest of
> git-annex's state=C2=BB

That's indeed a nice example of how to handle metadata in a better way.
But it does require more than a plain files, so publishing and archiving
the metadata requires additional tools (git in this case).

> I doubt this could be applied to `guix pack`, but it's an intereting
> approach to "sidecar" metadata

We could adapt the idea to the Guix store. Write the metadata to a
separate file in the store that has the same filename as the packed
archive, but an additional extension. Since the filename contains the
hash of the archive contents, the relation between data and metadata
is also maintained.

Konrad.