[gentoo-installer] a few different questions

[gentoo-installer] a few different questions

[Andrew Gaffney]

I've got a few questions about the proposed new installer:

1. I've heard that the core installer will be written in Python. Is this true?

2. Whether Python or not, will real-time frontends have to be written the same language as 
the core installer, or will it be controlled through a pipe or similar method?

3. Will the core installer have plugin capabilities (e.g. user-created 
configuration/installation steps), either scripted (bash) or coded (Python or whatever)?

4. Which existing installer will the new code be based from or will this be done 
completely from scratch possibly using existing concepts?

5. Are there any plans to include X along with Qt, GTK, Tcl/Tk, etc. on the LiveCD to 
allow for the creation of GUI installer frontends?

6. What is already done? What needs to be done? What is still up in the air?

7. How can I help? I don't know Python, but I have pretty decent bash - only since working 
on GLIS frontend ;) - and Perl skills. I don't know any Python, but I can always learn.

8. Anything else important that I might have missed?

-- 
Andrew Gaffney
System Administrator
Skyline Aeronautics, LLC.
776 North Bell Avenue
Chesterfield, MO 63005
636-357-1548


--
gentoo-installer@gentoo.org mailing list

Re: [gentoo-installer] a few different questions

[Kurt Lieber]

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

Have you read the requirements doc that esammer put together?  It answers
many/most of your questions.

http://dev.gentoo.org/~esammer/gli/gentoo_installer.txt
http://dev.gentoo.org/~esammer/gli/gli_uml.png
http://dev.gentoo.org/~esammer/gli/gli_use_case.png

On Mon, Feb 02, 2004 at 07:16:27AM -0600 or thereabouts, Andrew Gaffney wrote:
> 1. I've heard that the core installer will be written in Python. Is this 
> true?

That's the current plan, yes.

> 2. Whether Python or not, will real-time frontends have to be written the 
> same language as the core installer,

No.

> 3. Will the core installer have plugin capabilities (e.g. user-created 
> configuration/installation steps), either scripted (bash) or coded (Python 
> or whatever)?

Not sure, but I don't think it's currently planned to have a plugin
interface for the back end.

> 4. Which existing installer will the new code be based from or will this be 
> done completely from scratch possibly using existing concepts?

from scratch.

> 5. Are there any plans to include X along with Qt, GTK, Tcl/Tk, etc. on the 
> LiveCD to allow for the creation of GUI installer frontends?

haven't got that far yet.

> 6. What is already done? What needs to be done? What is still up in the air?

See the docs.

> 7. How can I help? I don't know Python, but I have pretty decent bash - 
> only since working on GLIS frontend ;) - and Perl skills. I don't know any 
> Python, but I can always learn.

See the docs.

> 8. Anything else important that I might have missed?

Yes.  See the docs. ;)

--kurt

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-installer] a few different questions

[Andrew Gaffney]

Kurt Lieber wrote:
> Have you read the requirements doc that esammer put together?  It answers
> many/most of your questions.
> 
> http://dev.gentoo.org/~esammer/gli/gentoo_installer.txt
> http://dev.gentoo.org/~esammer/gli/gli_uml.png
> http://dev.gentoo.org/~esammer/gli/gli_use_case.png

That first doc was especially informative. I'd seen the last two, but not the first.

> On Mon, Feb 02, 2004 at 07:16:27AM -0600 or thereabouts, Andrew Gaffney wrote:
> 
>>1. I've heard that the core installer will be written in Python. Is this 
>>true?
> 
> That's the current plan, yes.
> 
>>2. Whether Python or not, will real-time frontends have to be written the 
>>same language as the core installer,
> 
> No.
> 
>>3. Will the core installer have plugin capabilities (e.g. user-created 
>>configuration/installation steps), either scripted (bash) or coded (Python 
>>or whatever)?
> 
> Not sure, but I don't think it's currently planned to have a plugin
> interface for the back end.

For example, with the current CVS version of GLIS, you can create bash scripts that the 
installer will run before or after certain steps in the install process. Even if seldom 
used, it would be a handy (and easy to code) feature of GLI.

>>4. Which existing installer will the new code be based from or will this be 
>>done completely from scratch possibly using existing concepts?
> 
> from scratch.
> 
>>5. Are there any plans to include X along with Qt, GTK, Tcl/Tk, etc. on the 
>>LiveCD to allow for the creation of GUI installer frontends?
> 
> haven't got that far yet.
> 
>>6. What is already done? What needs to be done? What is still up in the air?
> 
> See the docs.
> 
>>7. How can I help? I don't know Python, but I have pretty decent bash - 
>>only since working on GLIS frontend ;) - and Perl skills. I don't know any 
>>Python, but I can always learn.
> 
> See the docs.
> 
>>8. Anything else important that I might have missed?
> 
> Yes.  See the docs. ;)

Alright, I get the point ;)

-- 
Andrew Gaffney
System Administrator
Skyline Aeronautics, LLC.
776 North Bell Avenue
Chesterfield, MO 63005
636-357-1548


--
gentoo-installer@gentoo.org mailing list

Re: [gentoo-installer] a few different questions

[Eric Sammer]

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

At risk of being extremely repetitive, it seems to be worth repeating.

Andrew Gaffney wrote:
> I've got a few questions about the proposed new installer:
> 
> 1. I've heard that the core installer will be written in Python. Is this 
> true?

Docs.

> 2. Whether Python or not, will real-time frontends have to be written 
> the same language as the core installer, or will it be controlled 
> through a pipe or similar method?

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." ;)

> 3. Will the core installer have plugin capabilities (e.g. user-created 
> configuration/installation steps), either scripted (bash) or coded 
> (Python or whatever)?

It depends on what you want to do. You can create arch templates (see 
the docs re: arch templates) that define the steps to perform and the 
actions that will be taken. Custom steps (see the docs re: steps) can be 
added increasing the front end (see the docs re: front end) options and 
what the user may do. Arch templates basically implement the control 
portion of the back end (see docs re: back end) and handle the flow control.

In short, docs. :)

> 4. Which existing installer will the new code be based from or will this 
> be done completely from scratch possibly using existing concepts?

Existing ideas will be taken and reused but all code will be a 
reimplementation to develop a generic platform. We'll be taking the best 
of each and running with it. Again, docs.

> 5. Are there any plans to include X along with Qt, GTK, Tcl/Tk, etc. on 
> the LiveCD to allow for the creation of GUI installer frontends?

There was talk of potentially creating a custom live cd with things that 
the installer can use / wants. Nothing was decided, but with catalyst, 
it becomes trivial (in comparison) so I imagine it will be decided later.

A simpler answer is the main live cd will almost never contain a full X 
environment. Love it or hate it - people will never agree and it's 
outside the scope of the installer project to try and force such issues 
either way.

> 6. What is already done? What needs to be done? What is still up in the 
> air?

Docs, docs, and docs.

> 7. How can I help?

Writing docs. Writing code. Offering ideas. Testing. Testing. Testing.

> I don't know Python, but I have pretty decent bash - 
> only since working on GLIS frontend ;) - and Perl skills. I don't know 
> any Python, but I can always learn.

While writing code is not to be discounted, there are many ways to help.

> 8. Anything else important that I might have missed?

The docs. :)

I'm sorry about busting your chops with regard to the docs. We have 
spent a lot of time putting them together to answer these kinds of 
questions (and others) and are trying to get people to look at them (and 
hopefully read them without glazing over). Of course, I jest for the 
most part but it can become difficult to repeat some things.

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

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

Re: [gentoo-installer] a few different questions

[Andrew Gaffney]

Eric Sammer wrote:
>> 2. Whether Python or not, will real-time frontends have to be written 
>> the same language as the core installer, or will it be controlled 
>> through a pipe or similar method?
> 
> 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. Just the same as most installers work, instead of how 
the GLIS frontend and backend works. 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.

>> I don't know Python, but I have pretty decent bash - only since 
>> working on GLIS frontend ;) - and Perl skills. I don't know any 
>> Python, but I can always learn.

Everybody is repeating themselves, even me. ;)

-- 
Andrew Gaffney
System Administrator
Skyline Aeronautics, LLC.
776 North Bell Avenue
Chesterfield, MO 63005
636-357-1548


--
gentoo-installer@gentoo.org mailing list

Re: [gentoo-installer] a few different questions

[Eric Sammer]

[-- 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 --]

Re: [gentoo-installer] a few different questions

[Paul de Vrieze]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tuesday 03 February 2004 05:13, Eric Sammer wrote:
>
> 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.

One could offer an option to force the actions to be done. It would be 
needed when users perform manual actions (but not in all cases). Of 
course forcing actions will disable the back button so probably warrants 
a warning.

>
> > 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.

It is the task of the frontend to either save up the actions or to send 
them to the backend immediately. As long as the backend can perform 
actions as soon as they are received (incomplete xml file) the backend 
can handle whatever you want.

Paul

- -- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAH3ZvbKx5DBjWFdsRAoWcAJ4xW6dh9D4w6in+flp0ws5nPkg5QwCgtQaS
DZopM4VszYS5hGYQiKX4acQ=
=Dn/z
-----END PGP SIGNATURE-----

--
gentoo-installer@gentoo.org mailing list

Re: [gentoo-installer] a few different questions

[Eric Sammer]

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

Paul de Vrieze wrote:
> On Tuesday 03 February 2004 05:13, Eric Sammer wrote:
> 
> One could offer an option to force the actions to be done. It would be 
> needed when users perform manual actions (but not in all cases). Of 
> course forcing actions will disable the back button so probably warrants 
> a warning.

This is true and could be done. Again, in the interest of a working 
prototype in a reasonable amount of time, I would say we'll come back to 
this as adding it at a later date will be trivial.

> It is the task of the frontend to either save up the actions or to send 
> them to the backend immediately.

Actually, settings are stuffed into GLIInstallProfile by the controller 
(part of the back end). The profile (data) and arch template (logic) are 
then put together in a similar fashion as XML and XSL are combined (in 
theory, not implementation). Of course, this will probably have to 
perform differently when doing immediate fire actions, but is another 
reason why I'd like to get things working before we do things like that.

> As long as the backend can perform 
> actions as soon as they are received (incomplete xml file) the backend 
> can handle whatever you want.

Again, messaging is not done as XML, only state is saved that way. This 
means that the firing of actions will probably be done by the controller 
calling the logic from the arch templates immediately. This is more of 
an implementation issue but is something that will be kept in mind.

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

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