unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: zimoun <zimon.toutoune@gmail.com>
To: Jason Self <jself@gnu.org>,
	guix-devel@gnu.org, Mark H Weaver <mhw@netris.org>
Subject: Re: Linux-libre source code will be taken offline
Date: Tue, 28 Sep 2021 10:43:20 +0200	[thread overview]
Message-ID: <86czotccpj.fsf@gmail.com> (raw)
In-Reply-To: <E1mV1Gf-00079S-RN@eggs.gnu.org>

Hi,

On Mon, 27 Sep 2021 at 17:46, Jason Self <jself@gnu.org> wrote:

>> https://linux-libre.fsfla.org/pub/linux-libre/releases/old/
>
> Yes. In gen6. They have been moved, not deleted.
>
> The versioning and locations in terms of gnuN and genN are knowable and
> predictable in advance. I wonder if there is, or could be made, a way to
> leverage that so that future moving of files can be done without
> causing problems, as long as the files themselves remain otherwise
> identical. As an example, the current cleanup scripts might be found in
> old/gen7 in the future. Although using git would probably be a better
> choice as it would seem to eliminate URL hunting.

Guix has the availability to transparently build any old version using
“guix time-machine”, i.e.,

  guix time-machine --commit=0c7c84407d65f3d03ad1fe3984ae4d524992f498 \
       -- build linux-libre

should build the Linux (libre) kernel as it was on 2020, 25th May.

If the user allow substitutes, then the necessary materials is fetch
from machines hosted in Berlin and maintain by Guix folk.

However, if the user does not allow substitutes, then the source are
first fetched from upstream.  Here several cases of origin.  Upstream is
still up, everything is fine.  Upstream disappeared in the meantime, it
depends on the “type” of the origin and the core issue is the mapping
between the information at package time (e.g., 2020, 25th May) and the
servers providing a fallback at request time for this missing source.

When the upstream source is a Git repo, this map is a simple
contend-addressed lookup by a (almost) straightforward resolver.

When the upstream source is not Git repo, this map becomes harder and
requires – in addition to a fallback server – an external resolver:
something that maps from the information at package time (2020, 25th
May) to the fallback server.

If the package linux-libre defined on 2020, 25th May (written on stone)
points to an URL source which disappears, this Guix time-machine feature
becomes doomed because URL is a really bad contend-addressed system as
all the broken internet shows us.

For sure, the infrastructure needs to evolve for a better future; easier
maintainability for instance.  However, please consider the archivist
point of view and help to not break the past. :-)


Cheers,
simon


  reply	other threads:[~2021-09-28  8:46 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-04 18:17 Linux-libre source code will be taken offline Leo Famulari
2021-09-04 20:32 ` Jason Self
2021-09-06 17:36   ` Leo Famulari
2021-09-27 22:30     ` Mark H Weaver
2021-09-27 23:17       ` Vagrant Cascadian
2021-09-28 13:05         ` Ludovic Courtès
2021-09-27 23:30       ` Leo Famulari
2021-09-28  0:13         ` zimoun
2021-09-28  0:17           ` zimoun
2021-09-28  0:46         ` Jason Self
2021-09-28  8:43           ` zimoun [this message]
2021-09-28 14:02             ` Jason Self
2021-09-28 14:30             ` Jason Self
2021-09-28 17:11               ` zimoun
2021-09-28 17:52                 ` Jason Self
2021-09-29  8:50                   ` zimoun
2021-10-08  1:58                     ` Maxim Cournoyer
2021-10-11  8:43                       ` zimoun
2021-09-08 22:00 ` Ludovic Courtès
2021-09-08 23:46   ` Why linux-libre source code is not in sources.json zimoun
2021-09-09  7:37     ` zimoun
2021-09-09  9:50       ` Maxime Devos
2021-09-09 17:18         ` zimoun
2021-09-11  0:22   ` Linux-libre source code via SWH sources.json zimoun

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=86czotccpj.fsf@gmail.com \
    --to=zimon.toutoune@gmail.com \
    --cc=guix-devel@gnu.org \
    --cc=jself@gnu.org \
    --cc=mhw@netris.org \
    /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).