System installation is very different from building or the installation of optional packages.
There is a minimal set of packages that must be installed to have a working system. A portion of those packages are system HW dependent. Conceptually I describe it as follows: Base system components Hardware specific components Optional use case specific components At one time, the SunOS install broke out the use case specific components as options. Historically I always selected everything except games if that was listed as a separate set. Otherwise I simply took "all". However, that was at a time when "all" fit on one or two 60 MB 1/4" tapes. We are far past that mark now. Despite that, disk is now so cheap I'd be inclined to install "all" if there were a good mechanism for selecting the window manager at login. This can be done, but to the best of my knowledge the current arrangement is clumsy and may well harbor pathological cases. I'm sure Alan is far more aware of those than I ever wish to know. As I understand it, the choice of package at install time also configures the window manager. That works for most people, but makes experimenting with different window managers awkward. Disk is currently ~$0.02/GB, so we're talking nickels and dimes to just dump it all onto the disk now. That's actually a lot faster to do if it's just a large cpio(1) archive. However, the hardware specific parts need to be handled in a separate phase of the install. Currently we have multiple installs depending upon whether it is a /dev/console or /dev/tty[ab] connected system. I don't know how that is currently implemented, though I do see that there is logic that is detecting the presence of serial ports. I shall know more when the serial port kits for the Z400 I ordered yesterday arrive. IIRC the traditional install booted a miniroot and ran a shell script from tape. It's not flashy, but it worked very well. Most importantly, it was easy to discover, understand and modify. As security was not an issue for my unconnected home system, flipping the diag switch on my 3/60 booted miniroot from a small sliver of disk I set aside for that. It was rarely needed, but it meant I did not need the install media to bring up a corrupted system. The system install task has not changed so it's difficult for me to see why we should have more than a single install script that reads a set of files which describe the contents of the 3 phases I outlined above. That makes it very simple to add whatever HW detection logic is needed in a single script which at the HW phase queries the system and generates the HW specific pkg list. That's how I'd handle the task. I'll let someone who knows the current system comment on what is being done now. I have a machine HW failure to diagnose :-( Reg On Saturday, March 13, 2021, 11:29:32 AM CST, Alan Coopersmith <alan.coopersm...@oracle.com> wrote: On 3/13/21 4:27 AM, Stephan Althaus wrote: > But i don't know how to integrate this into the build system nor at packaging > level. There is no way to script this inside IPS packages - instead your script would have to be outside the packaging system and run pkg commands to install/uninstall the packages as needed. -alan- _______________________________________________ openindiana-discuss mailing list openindiana-discuss@openindiana.org https://openindiana.org/mailman/listinfo/openindiana-discuss _______________________________________________ openindiana-discuss mailing list openindiana-discuss@openindiana.org https://openindiana.org/mailman/listinfo/openindiana-discuss
