all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: ng0 <ng0@n0.is>
To: "Ludovic Courtès" <ludo@gnu.org>
Cc: Guix-devel <guix-devel@gnu.org>
Subject: Re: Installation
Date: Thu, 18 Jan 2018 12:05:42 +0000	[thread overview]
Message-ID: <20180118120542.rymr5cwtrxogirsa@abyayala> (raw)
In-Reply-To: <877esfbgtx.fsf@gnu.org>

[-- Attachment #1: Type: text/plain, Size: 2320 bytes --]

Ludovic Courtès transcribed 1.5K bytes:
> Ricardo Wurmus <rekado@elephly.net> skribis:
> 
> > Ludovic Courtès <ludo@gnu.org> writes:
> >
> >> Gábor Boskovits <boskovits@gmail.com> skribis:
> >>
> >>> I believe, that we could make a powerful extension to guixsd if we could do
> >>> an installation from an installation description.
> >>>
> >>> I think this installation description should look like the operating-system description we
> >>> already have.
> >>
> >> In what way would it defer?  :-)
> >>
> >> ‘operating-system’ *is* an “installation description.”
> >
> > I guess it would differ from what we have currently in that it would
> > also specify partitioning information, which is not handled by
> > “operating-system”.
> >
> > Does it make sense to extend “operating-system” such that disk
> > partitioning information could be included and (*holds breath*) acted
> > upon automatically?
> 
> I suppose only ‘guix system init’ could actually use that information.
> 
> Perhaps we could have a separate partitioning description, and users
> could optionally run:
> 
>   guix system init --partitioning=part.scm config.scm
> 
> ?
> 
> Is it really an improvement over writing a Parted script, which is
> something people can already do?

My approach is different (making a templating system around Guix that translates
a number of not yet defined language inputs into a file that can be reused by
Guix), but I think we should make use of the guix system abilities and not rely
on the fact that people could already do this with an external tool.

> > Acting on partitioning info is a little scary because it can easily lead
> > to data loss upon reconfiguration.  Small bugs could lead to very big
> > problems, so maybe this should not be default behaviour.
> 
> It’s definitely scary.

Do we have the ability to separate features, like --enable-experimental passed
to configure build Guix with certain features that might break your OS? Otoh
we already presume that people setting up GuixSD today know enough about systems
to recover from failures (which is another undocumented problem/usecase with GuixSD).

> Ludo’.
> 
> 

-- 
ng0 :: https://ea.n0.is
A88C8ADD129828D7EAC02E52E22F9BBFEE348588 :: https://ea.n0.is/keys/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2018-01-18 11:06 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-09 12:43 Installation Gábor Boskovits
2018-01-17 14:35 ` Installation Ludovic Courtès
2018-01-17 15:47   ` Installation Ricardo Wurmus
2018-01-17 19:35     ` Installation Gábor Boskovits
2018-01-18 10:27       ` Installation Ludovic Courtès
2018-01-18 10:29     ` Installation Ludovic Courtès
2018-01-18 12:05       ` ng0 [this message]
2018-01-18 15:11         ` Installation Ricardo Wurmus
2018-01-18 16:41           ` Installation myglc2
2018-01-22  4:38       ` Installation Chris Marusich
2018-01-22  8:29         ` Installation Gábor Boskovits
2018-01-18  2:29   ` Installation George myglc2 Clemmer
2018-01-18  9:29     ` Drive identifiers Danny Milosavljevic
2018-01-18  9:39       ` Danny Milosavljevic
2018-01-18 10:32         ` Ludovic Courtès
2018-01-18 11:01           ` Danny Milosavljevic
2018-01-19 14:35           ` Danny Milosavljevic
2018-01-18 20:10       ` myglc2
2018-01-19  8:27         ` Danny Milosavljevic
2018-01-19  0:43       ` myglc2
2018-01-19  7:22         ` Danny Milosavljevic
2018-01-19 16:42         ` Ricardo Wurmus
2018-01-24 14:12           ` Ludovic Courtès

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

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

  git send-email \
    --in-reply-to=20180118120542.rymr5cwtrxogirsa@abyayala \
    --to=ng0@n0.is \
    --cc=guix-devel@gnu.org \
    --cc=ludo@gnu.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 external index

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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.