Re: [Cooker] A suggestion

2001-02-24 Thread Leon Brooks

Steve Wray wrote:

>> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
>> the only pb is that i doesn't warn that installation is over, except for X
>> configuration. Just reboot on installed system and call XFdrake.

> Oh well in *that* case it should give a comforting
> message which would stop the unwary from going thru the install
> again...
> :)

Such as? If they booted from CD, no context would be kept, unless you 
(the installer program) scanned for (and found) the hard drives and 
decided that the system installed there was itself. Borrowing bits in 
(e.g.) NVR is kind of risk because some BIOSes have very fixed ideas 
about what should be done with undocumented NVR bits.

-- 
Neonle will continue to be rude, and will nretend that you had a
small stroke which makes you unable to say or see the letter "n".
Stunid nractical joke, if you ask me.  Bunch of noon-heads, huh?
-- Fred Barling, Humorscope





Re: [Cooker] A suggestion

2001-02-24 Thread Leon Brooks

Pixel wrote:

> James Mitchell <[EMAIL PROTECTED]> writes:
>> This may well be too much work at this point, but it would be very nice if the
>> Mandrake installer followed the example of the Solaris 8 installer and got all
>> the configuration possible out of the way beforehand.  Get the network

> - mkbootdisk must be interactive

But can be cued right at the start. Would it hurt to boot from floppy 
the first time if the resulting disk were left in the drive. Boy, I wish 
floppies were soft-activated like on Mac! Also, I very rarely make a 
boot disk since the CD is a good enough rescue disk should things not go 
right.

> - X configuration testing interactivaty needs X installed, and test can freeze
> the box, so must be done at the very end of install.

I never test X on install anyway (I test after everything else is known 
to work) so I would appreciate a way to tell the installer this right at 
the start. Even if I wanted to test X, I would appreciate the machine 
breezing its way through everything else, and writing it all to disk, 
and sync()ing, and then testing, so I can walk off and leave an install 
to run to completion, presuming the test succeeds, and to a highly 
useable state if the test kills the machine.

-- 
"Diaper spelled backwards is Repaid.  Think about it."
 -- Marshall McLuhan





Re: [Cooker] A suggestion

2001-02-22 Thread James mitchell


--- Pixel <[EMAIL PROTECTED]> wrote:
> James Mitchell <[EMAIL PROTECTED]> writes:
> 
> > This may well be too much work at this point, but it would be
> > very nice if the Mandrake installer followed the example of the
> > Solaris 8 installer and got all the configuration possible out
> > of the way beforehand.
> 
> pbs:
> 
> - at least partitioning must be done before otherwise swap is not
> there.
> - timezones are taken from glibc package (would need copying like
> redhat is doing otherwise)
> - printers list are taken from rhs-printfilters / cups (would need
> copying)
> - mkbootdisk must be interactive
> - X configuration testing interactivaty needs X installed, and test
> can freeze the box, so must be done at the very end of install.
> - a lot of stuff modify files that are not installed yet (like
> draknet)
> 
> - to sum up, it would need a lot of change... but i agree this is an
> idea worth thinking :)
> 
> Of course, there must be other pbs that i missed.

I never said it was easy... giving a bit of thought to things, it looks
a lot like a huge mess to get right.  Either all of the configuration
should be moved up front of package installation, like solaris, and
then cached, to be applied after/as the packages are installed, roughly
as Solaris does it, or nearly all the configuration should be moved to
happen on the first boot, after the packages are installed and the
machine successfully booted, the way that Windows does it.

I think that the latter approach is probably cleaner for the typical
end-user, but both present problems that I suspect are equally sticky
to fix.  The Solaris approach keeps the 'duplicate install' floppy
process clean (perhaps even a little cleaner), but it means that the
installer has to cache a lot of state until after the files that need
changing are installed.  The Windows approach holds off untill the
system is already mostly-sane, which ensures that the changes made are
done in real-time, based on up-to-date information.  This appears to me
to break the 'duplicate install' floppy as it stands, probably
requiring support for changing all of the available options in the
install process anyway, and creating a command to make the 'duplicate
install' disc.

There is a new solaris install process in version 8 that might be more
helpfull.  It partitions the disk, sets up some swap, and then
bootstraps in a mini-OS.  On reboot a second-stage installer comes up,
where you select packages, and do all remaining configuration.  This is
also roughly what I remember Debian doing.  I don't particularly like
it as Solaris does it, but that may have a lot to do with my only doing
installs on headless servers and three-generation old workstations with
1x CDROMS, but in the long run this is probably the cleanest approach.

There is probably a quick-fix available here, though.  The main
manefestation of my concern is that installing packages typically takes
me an hour or more, even with a fast CD-ROM, or copying them from a
spare hard disk, and things like configuring X and installer bugs can
screw the whole thing after its finished.  Moving lilo/grub config in
front of package selection, and executing it as soon as the packages
are installed might be a good compromise.  Another option would be to
write a flag to disk to track the state of the install, then, if the
installer notices the flag, it can offer the option of resuming
instalation where it left off (I think Windows does something like
this).

James Mitchell



__
Do You Yahoo!?
Yahoo! Auctions - Buy the things you want at great prices! http://auctions.yahoo.com/




RE: [Cooker] A suggestion

2001-02-22 Thread Steve Wray

> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
>
> "Steve Wray" <[EMAIL PROTECTED]> writes:
>
> > This is a reason to get it out of the way ASAP. So that you don't
> > slog your way thru all that work only to have it crash right at
> > the end
>
> the only pb is that i doesn't warn that installation is over, except for X
> configuration. Just reboot on installed system and call XFdrake.
>

Oh well in *that* case it should give a comforting
message which would stop the unwary from going thru the install
again...
:)






Re: [Cooker] A suggestion

2001-02-22 Thread Pixel

"Steve Wray" <[EMAIL PROTECTED]> writes:

> This is a reason to get it out of the way ASAP. So that you don't
> slog your way thru all that work only to have it crash right at
> the end

the only pb is that i doesn't warn that installation is over, except for X
configuration. Just reboot on installed system and call XFdrake.




RE: [Cooker] A suggestion

2001-02-22 Thread Steve Wray

> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> 
> James Mitchell <[EMAIL PROTECTED]> writes:
> 
> > This may well be too much work at this point, but it would be 
> very nice if the
> > Mandrake installer followed the example of the Solaris 8 
> installer and got all
> > the configuration possible out of the way beforehand.  Get the network
> 
> pbs:
[big snip]
> - X configuration testing interactivaty needs X installed, and 
> test can freeze the box, so must be done at the very end of install.

This is a reason to get it out of the way ASAP. So that you don't
slog your way thru all that work only to have it crash right at
the end
:)

Most of the other hardware probing is done at the beginning,
possibly for just this reason?






Re: [Cooker] A suggestion

2001-02-22 Thread Pixel

James Mitchell <[EMAIL PROTECTED]> writes:

> This may well be too much work at this point, but it would be very nice if the
> Mandrake installer followed the example of the Solaris 8 installer and got all
> the configuration possible out of the way beforehand.  Get the network

pbs:

- at least partitioning must be done before otherwise swap is not there.
- timezones are taken from glibc package (would need copying like redhat is
doing otherwise)
- printers list are taken from rhs-printfilters / cups (would need copying)
- mkbootdisk must be interactive
- X configuration testing interactivaty needs X installed, and test can freeze
the box, so must be done at the very end of install.
- a lot of stuff modify files that are not installed yet (like draknet)

- to sum up, it would need a lot of change... but i agree this is an idea worth
thinking :)

Of course, there must be other pbs that i missed.




Re: [Cooker] a suggestion...

2000-05-02 Thread Pixel

Pascal Grosse <[EMAIL PROTECTED]> writes:

[...]

> this behaviour, but I think it would be a cool feature
> to add for the next mandrake (7.2?). Maybe something
> like a message showing the dependencies and asking if
> I am sure about deselecting would be great. 

it think you missed the mean of the checkbox. It doesn't toggle between with or
without dependencies. It toggles between asking or not asking when fulfilling
deps.

maybe the text should be changed?




[Cooker] a suggestion...

2000-05-02 Thread Pascal Grosse

Hi all,

When I tried Mdk 7.1b, I liked very much the automatic 
gestion of dependencies during individual package 
selection in expert mode. But I missed one feature :
when deselecting one package (I cannot remember which 
one), the installer deselected xemacs automatically.
There's nothing anormal to that, but I would have liked
the program to warn me about that. I know this is not a
bug, and that there is not enough time now to change 
this behaviour, but I think it would be a cool feature
to add for the next mandrake (7.2?). Maybe something
like a message showing the dependencies and asking if
I am sure about deselecting would be great. The SuSE 
yast does something like that, and it should not bother
someone installing in expert mode anyway... Debian's 
dselect can also be a good inspiration for what could
be done here (even if it is a pain to use).

Pascal Grosse