[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [bug#44199] [PATCH 0/1] An origin method for GNUnet FS URI's

From: Maxime Devos
Subject: Re: [bug#44199] [PATCH 0/1] An origin method for GNUnet FS URI's
Date: Sun, 01 Nov 2020 01:05:53 +0100
User-agent: Evolution 3.34.2

[CC'd to Timothy Sample because of discussion of defining a new format
for disarchive, and to gnunet-developers because of obvious reasons]

A small status update!

zimoun schreef op di 27-10-2020 om 14:39 [+0100]:
> [...]
> The story about archives as tarball is a bit more complicated.  The
> main
> issue –as I understand it– can be summarized as: Guix knows the URL,
> the
> integrity checksum and only at package time the content of the
> tarball.
> Later in time, it is difficult to lookup because of this very
> address;
> and some are around: nar, swh-id, ipfs, gnunet, etc.
> Bridges to reassemble the content are currently discussed, e.g.,
>    <>
>    <>
> Well, today the fallback of tarball archive to SWH is not reliable.
> What is your question? ;-)

I looked a bit into the GNUnet FS code and disarchive discussions. The
part about tarballs seemed particularily relevant, as well as some
older discussion on preserving the executable bit when using IPFS.

Some issues with using GNUnet's directory format in GNUnet for Guix
substitutes to address:

* directory entries are not placed in any particular order.
  Solution: sort by file-name

* there is no executable bit.
  Solution: define a new metadata property (*).
  This should only take a small patch to libextractor.

  (*) Not sure about the correct terminology

* GNUnet sometimes inlines small files in directories,
  but strictly speaking when to do so is left up to the implementation.
  Solution: pick a fixed reference implementation.

* By default, when publishing, gnunet-publish uses libextractor
  to figure out some meta-data (e.g. title, mime-type, album name),
  which may return different meta-data depending on the implementation.

  Solution: disable the use of libextractor, at least when GNUnet is
  used by Guix.

I'm currently porting the directory creation code of GNUnet to Scheme
(but not any other GNUnet code), to be used by Guix (for publishing
substitutes) and disarchive (for reconstructing GNUnet directories).

After addressing these issues, I believe I will end up with a fairly
well-defined archive format.


Attachment: signature.asc
Description: This is a digitally signed message part

reply via email to

[Prev in Thread] Current Thread [Next in Thread]