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 installation.
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 unattended installation. 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 this nice?
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...
Greets,
David Hinz
mf schrieb:
Hiya!
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: {systemroot}\system32\somelib.dll {targetdir}\someapp.exe logo.bmp package.rpkgscript
The rpkgscript should be able to invoke user interaction with simple javascript-like alerts asking for input, but the named variables for 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> </form> <wizardctrl prev="1", next=dest?1:0, cancel="1" /> }
*I removed the rest, as it doesn't matter for my mail...*