guix-devel
[Top][All Lists]
Advanced

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

Re: Adding Substitute Mirrors page to installer


From: raid5atemyhomework
Subject: Re: Adding Substitute Mirrors page to installer
Date: Thu, 13 May 2021 01:27:40 +0000

bump

> Hello Mathieu,
>
> > Hello,
> > Thanks for this patch, it seems to work fine!
> >
> > > -             ;; Extract the substitute URLs of the user configuration.
> > >
> > >
> > > -             (os              (read-operating-system 
> > > (%installer-configuration-file)))
> > >
> > >
> > > -             (substitute-urls (and=> (find
> > >
> > >
> > > -                                       (lambda (service)
> > >
> > >
> > > -                                         (eq? guix-service-type
> > >
> > >
> > > -                                              (service-kind service)))
> > >
> > >
> > > -                                       (operating-system-services os))
> > >
> > >
> > > -                                     (compose 
> > > guix-configuration-substitute-urls
> > >
> > >
> > > -                                              service-value)))
> > >
> > >
> >
> > We could make the mirror selection a proper step, adding it to (gnu
> > installer record). Then in (gnu installer), you could add:
> > --8<---------------cut here---------------start------------->8---
> > (installer-step
> > (id 'mirrors)
> > (description (G_ "Mirror substitute server"))
> > (compute (lambda _
> > ((installer-mirrors-page current-installer)))))
> > --8<---------------cut here---------------end--------------->8---
> > This way, you should be able to select the step result in
> > "run-final-page" this way:
> > --8<---------------cut here---------------start------------->8---
> > (let* ((configuration (format-configuration prev-steps result))
> > (user-partitions (result-step result 'partition))
> > (locale (result-step result 'locale))
> > (users (result-step result 'user))
> > (mirrors (result-step result 'mirrors))
> > (install-ok?
> > (with-mounted-partitions
> > user-partitions
> > (configuration->file configuration)
> >
> >          (run-config-display-page #:locale locale)
> >          (run-install-shell locale #:users users #:mirrors mirrors))))
> >
> >
> > ...)
> > --8<---------------cut here---------------end--------------->8---
> > That would avoid the need to parse the resulting configuration file.
>
> I don't think that will work.
>
> The intent is that mirror selection affects two things:
>
> -   The actual installed system, i.e. `/etc/config.scm`.
> -   The installer's Guix Daemon.
>
>     If my understanding of the above is correct, it will only affect the 
> installer's Guix Daemon (via `run-install-shell` which will call into 
> `install-system`, presumably with the added argument), but not affect the 
> installed system, because the `configuration` cannot be modified by the 
> `'mirrors` page in the above construction.
>     Currently what the installer assumes is that a page will at most include 
> a unique entry into the `operating-system`, but it cannot handle a page which 
> modifies the entry created by a previous page.
>
>     It would be a breakage of expectations to ask the user to select some 
> mirror, then the installed system, when `guix system reconfigure`d, uses the 
> default `ci.guix.gnu.org`.
>
>     My patch affects both, because that is logically what a user would 
> expect, after all, they selected a particular server to install from.
>     Thus, they expect, that both the installed system, and the installer, 
> will use the selected mirror.
>     Of course, it feels somewhat dirty, as there is a need to read the 
> configuration file.
>     It would be cleaner if a page could affect the field created by a 
> previous page.
>
>     For example, perhaps the result of a page is not an AST that is a field 
> of an `operating-system` form, but instead a procedure that accepts a 
> `(operating-system ...)` form and returns it.
>     Most existing pages would just append their keyed sub-form.
>     However the `mirrors` page would modify an existing `services` field in 
> the input `operating-system` form instead.
>
>
> > > +(define (run-substitute-mirror-page)
> > >
> > > -   (let ((title (G_ "Substitute mirror")))
> > >
> > > -   (run-listbox-selection-page
> > >
> > > -          #:title title
> > >
> > >
> > > -          #:info-text (G_ "Choose a server to get substitutes from.
> > >
> > >
> > > -
> > >
> > > +Depending on your location, the official substitutes server can be slow; 
> > > \
> > > +in that case, using a mirror may be faster.")
> >
> > I wonder if it would make sense to select multiple mirrors, as fallback
> > if the preferred mirror is not up to date. We could also add the
> > possibility for the user to add a mirror manually.
> > In that case, the mirror page could look like the "User creation" page,
> > with an "Add" button opening a popup proposing to type a mirror URL or
> > to select one from an existing list.
> > WDYT?
>
> I think Less is More, and deploying an installer with a simple "select one 
> mirror" pagenow will cover 90% of use-cases, and we can add the more 
> complicated page later when there is more time.
>
> In particular, there is really only one public mirror of Guix that I know of, 
> the SJTU mirror, so all the flexibility here is not very useful, at least not 
> to me.
> Since "multiple mirrors" aren't even available yet anyway, why add the 
> complication now?
>
> Maybe you can encourage more people to actually run mirrors if the installer 
> has a visible "select mirrors" page, so that you can actually get more than 
> just the SJTU mirror and "select multiple mirrors" is now a (good) problem to 
> have to solve.
>
> For now I think a simple "select one mirror, we'll add ci.guix.gnu.org as a 
> fallback" would be better.
> You can add a "select multiple mirrors in an order I want to specify" later, 
> when there are multiple mirrors existing.
>
> Thanks
> raid5atemyhomework





reply via email to

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