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/