[ros-dev] Re: New Setup system
post.center at gmail.com
Mon Jan 30 23:10:21 CET 2006
Sounds lie you are thinking just like crashfourit and me, so I think we
three should be able to start with this project (even if I won't be of
much use atm, as I'm just beginning to learn c++).
Actually there is one big difference between your idea and mine: You
want these packages in addition to our current ReactOS base, I want
everything to be package based. There would be a base package, a freeldr
package and so on.
The thing with the live cd also crossed my mind and seems to be a good
idea, the live-cd is just based on the ReactOS version you are about to
install, so there should be no problem with driver detection and
Basically you would do this: Put the install-cd into your cd-drive and
boot from it. The live-cd will boot up and you will see a ReactOS that
started a setup application instead of explorer.exe. Then you can choose
between installing ReactOS or trying out ReactOS. If you press "Try" the
setup app will close and start explorer.exe, if you press install, the
setup will continue and start with the installation.
You will select a basic setup (e.g. server, home desktop, enterprise
desktop...) and will then be able to (de)select different packages.
After this step setup knows how many space you will need on your
harddisk and will start a partition manager (maybe something like
qtparted, but at least as good as the MS solution, even if it should be
a lot better...).
Now I have to describe a little thing: I want packages to have a flag
that tells setup if there are any questions that can't be skipped by
Setup will scan the installation disk for such packages and will ask the
questions, that can't be skipped.
After this all packages the user selected will be unpacked to the
harddisk, execute all scripts included in the packages, and setup will
reboot for the first time.
Now the new ReactOS will be booted and is ready for use!
Every device ReactOS has a driver for is already installed, all users
you wanted to have are created, all applications are installed, isn't
For the internals, what you describe looks good, and I don't think we
should talk about the script layout that much now, but we should define
some basic things, like how we should store the basic information about
this package (dependencies, ...) and the internalt folder structure.
And then we have to have a look at the ReactOS Package Manager.
But not today, I'm getting tired...
> I think, *if* we are going to revamp our setup, we will have to look at
> a whole set of areas where improvement is possible. I have installed
> countless windozes from Win3.11 up to Server 2003 and Longhorn Beta 1,
> have also installed alternative operating systems *and* created
> installers for applications with varied levels of attendance (most of
> them only have two buttons, Install and Exit, but I've also done
> wizard-based stuff), so I think I've sort of got an idea what's needed.
> Now, reboot count has already been mentioned. It would be really cool if
> we can require no more than 2 reboots for an entire system install. I
> don't know the technicalities behind driver detection and *why* Windows
> always needs to reboot 2 to 3 times, but I trust someone like Alex will
> come up and shoot the whole idea down (like usual :D).
> Ideally, I would envision this as a realistic way of handling reboots:
> Boot from CD: The LiveCD is booted into a WinPE-like environment,
> everything from copying files to detecting hardware and installing
> drivers is done in the same session, and after installation is complete
> setup reboots into the newly installed ReactOS system. (1 reboot total)
> Install from running ReactOS/Windows session: Required files are copied
> to harddrive, and setup reboots into the installation environment, where
> everything from configuring the system to detecting hardware and
> installing drivers is done in the same session, and after installation
> is complete setup reboots into the newly installed ReactOS system. (2
> reboots total)
> Packages have also been mentioned. This whole Vista thing sounds like a
> stupid idea, I smell a lot of reverse engineering in the air (it would
> be a joke to assume Microsoft would document everything properly), and a
> lot of limitations because we have to stick to something. Also, it would
> be assuming Microsoft has come up with something smart, and quite
> frankly I don't think they have. It's worthwhile to discuss a lot and
> come up with something well-thought about, seeing that package
> management is very prone to preference. I have seen people praise RPM
> into the heavens and others curse it for its dependancy hell, and the
> same goes for every other package system in existance.
> Personally, I would like to see simplicity kept with a max of
> installation flexibility. Borrowing from Slackware's package system (the
> simplest package system in existance), a clever idea might be to have a
> single archive for a package containing all necessary files in a virtual
> directory structure that mimics the target structure (similar to
> Microsoft's $OEM$ dir on branded/slipstreamed Windows installation CDs),
> along with an install script in the root of the archive. Everybody's all
> in love with XML files, but personally I envision a script format more
> usable for this purpose. As for what compression format, it really
> doesn't matter much, but considering we're an FOSS operating system
> gearing towards a very pluriform hardware platform (ranging from 486 to
> Athlon64, and even other architectures), we'd be better off with
> something that doesn't need an overclocked rig to decompress with
> reasonable speed, so I'm thinking either tar-gzip or tar-bz2. The file
> extension would probably be best off renamed (so it's a tgz in disguise)
> to something like .RPKG.
> I'm envisioning directory structure inside the archive like so:
> The rpkgscript should be able to invoke user interaction with simple
> these should all be definable as arguments (and have default values,
> which in unattended mode will be used). So for instance, let's say we
> call a wizard dialog from our script:
> wizardDlg(pathstr "targetdir", bmp "logo")
> <wizardbmp null, src="logo" />
> <static null, left="10px", width="*">Please enter the target
> directory you would like to install Some App into.</static>
> <br />
> <form dest, var="targetdir", type="path">
> <input null, type="text", left="10px", width="*">
> <button type="browse">Browse...</button>
> <wizardctrl prev="1", next=dest?1:0, cancel="1" />
> *I removed the rest, as it doesn't matter for my mail...*
More information about the Ros-dev