public inbox for gentoo-installer@lists.gentoo.org
 help / color / mirror / Atom feed
From: Eric Sammer <esammer@gentoo.org>
To: gentoo-installer@lists.gentoo.org
Subject: Re: [gentoo-installer] a few different questions
Date: Mon, 02 Feb 2004 23:13:45 -0500	[thread overview]
Message-ID: <401F1FF9.2000405@gentoo.org> (raw)
In-Reply-To: <401F1986.3020607@skylineaero.com>

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

Andrew Gaffney wrote:
> Eric Sammer wrote:
>> I'm not entirely sure what you mean by "real time" but the physical 
>> commands will be shelled out where required. If you're asking if we're 
>> going to reimplement fdisk in pure python, the answer is a certain 
>> "no." ;)
> 
> By real-time, I mean that if you create your partition layout in the 
> frontend and then click 'Next ->', it will fire off a function call to 
> the installer core which will put that partition layout into effect.

Aha. I see now. No, all action is delayed until all decision making is 
complete. This is for two reasons (one intended, one a nice side 
effect): 1. The front end is acting as just a special kind of install 
profile editor of sorts so teh backend is really the automated 
deployment part with some of the features missing. This makes for very 
good reuse of design / code. 2. Users like to experiment and a "Back" 
button is a nice comfort to newer users. Blowing away their partition 
table prior to all decisions being made might upset some folks.

> Just the same as most installers work, instead of how the GLIS frontend 
> and backend works.

Actually, as far as I know, most installers delay destructive actions 
even if they *say* they don't. Of course, I haven't looked at the code 
for any of these products recently, but it seems logical that if you 
performed a destructive operation such as altering a partition table 
*and* you provided a back button... well, I just don't know how you'd 
make that work in a reasonable, predictable, and safe fashion.

> With the frontend that Scott Hadfield and I jointly 
> wrote for GLIS, the frontend creates the config file which gets passed 
> to the backend when the config is done. That is not real-time.

Right. This will function in a similar manner. I think this is a better 
design than firing off each part piecemeal.

> Everybody is repeating themselves, even me. ;)

It's good for all the stuff it's good for.

-- 
Eric Sammer
Gentoo Linux
http://www.gentoo.org

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

  reply	other threads:[~2004-02-03  4:25 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-02-02 13:16 [gentoo-installer] a few different questions Andrew Gaffney
2004-02-02 14:00 ` Kurt Lieber
2004-02-02 14:06   ` Andrew Gaffney
2004-02-03  3:37 ` Eric Sammer
2004-02-03  3:46   ` Andrew Gaffney
2004-02-03  4:13     ` Eric Sammer [this message]
2004-02-03 10:22       ` Paul de Vrieze
2004-02-03 16:59         ` Eric Sammer

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=401F1FF9.2000405@gentoo.org \
    --to=esammer@gentoo.org \
    --cc=gentoo-installer@lists.gentoo.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.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox