Here's a list of enhancements from 0.3 that I would like to see for 0.4... ideas taken from my own little noodle and also from #gentoo-installer. Expect this list to shrink/grow as time goes on. #1. <code|work> agaffney: remind me to put the auto-add scsi into the TODO list for the next release #2. Add support for kernelpkgs.txt to the installer... this file lists the packages in livecd-stage2 that were built against "livecd-kernel" allowing the user to get pre-compiled versions of external modules that may be required for them to have full functionality #3. Add elilo support on x86 - sure we don't need it now, but we will (and I'll definitely be assisting with this one) #4. "Mode" selection? Perhaps some way for the user to say "I only want binaries" or "I have no network connection" rather than having to select multiple options to get this kind of support
#5. Reduced memory footprint (as much as possible, of course)
Is the 0.3 release available yet? or was this just internal? The project page (http://www.gentoo.org/proj/en/releng/installer/) Still shows 0.2 as the current release. Also is the AMD 64 version a "complete" cd yet.
Sorry, your questions are *quite* irrelevant for this bug, but I'll answer them anyway. Yes, 0.3 is released, it was used on 2006.0 for both x86 and amd64. As for it being "complete", I have no idea what you're talking about. Anyway, these questions perhaps belong on the gentoo-installer mailing list and not on this bug, which is a specific set of feature requests from release engineering to the installer team.
Moving to Release Media/Installer.
#6 (Related to #4) i would be great to have predifined "sets" like "minimal install" (without X), "basic install", "homeworker" (office install), "developer" #7 would it make sense to have several levels of emerging packages? like minimal install first (ssh,samba if selected), next level X & co, ... It would greatly help the user to resume a broken install... (since the chance of a broken install is proportional increasing with the number of packages, the "important" ones should be emerged first)
(In reply to comment #5) > #6 (Related to #4) i would be great to have predifined "sets" like "minimal > install" (without X), "basic install", "homeworker" (office install), > "developer" Gentoo does not want this, as it reduces choices for the user. We aren't trying to be Red Hat here. Also, remember that the Installer is primarily a deployment tool. These types of functions wouldn't be very valuable in a deployment tool so much as they would be in an installer geared towards end-user ease-of-use, which is not one of the GLI goals. > #7 would it make sense to have several levels of emerging packages? like > minimal install first (ssh,samba if selected), next level X & co, ... > It would greatly help the user to resume a broken install... (since the chance > of a broken install is proportional increasing with the number of packages, the > "important" ones should be emerged first) Not really. The stage stuff is already done first. However, if you add something to USE that wou;d pull X into one of the early stages, there's *nothing* that we can do about it without deciding to ditch portage entirely during the install, which is not something we are either willing or prepared to do. Anyway, this bug is really an internal bug between Release Engineering and the Installer team and isn't meant for general usage or for user requests. I'm going to restrict it to developers only to keep more of these insightful comments from polluting this bug. ;]
#6. This one might not be feasible, but I'd think it would be something that would be useful. Because we pull in ssmtp by default into our systems when we merge a cron daemon, I think it would be nice if we did *something* like the following: If a user selects a virtual/mta mailer, such as sendmail/exim/postfix, we ask if they wish to remove ssmtp when doing so, or enable USE=mailwrapper" or whatever other solution you find to be more acceptable. Basically, a person should be able to select their own MTA and we should be able to support it, rather then causing a failure.
It was something we had thought about a while ago. There's even a separate item in the IP for the MTA. The logic for handling it was never completed and neither FE uses it. I'm not sure what the best way to handle this is.
How about if a user selects a mta, we merge it before the cron daemon? That should resolve that one... Also: Separate global and local USE into 2 screens... keep global use *before* package selection, and local USE *after* package selection, trimmed to only what is in the selected packages/dependencies I don't know how hard it would be... but it would *own* like that...
A user shouldn't be able to select GRP when doing a networked install. Basically, the modes should be as follows: Standard (stage3 only, --sync) Advanced (anything, but you're on your own) Networkless (dynamic stage3, GRP) That should cover it. Most people will use the first or the third. The second one can be totally ignored unless peopel provide patches. ;]
Still on the list: 1. Add support for kernelpkgs.txt to the installer... this file lists the packages in livecd-stage2 that were built against "livecd-kernel" allowing the user to get pre-compiled versions of external modules that may be required for them to have full functionality 2. Add elilo support on x86 - sure we don't need it now, but we will (and I'll definitely be assisting with this one) 3. smarter mta handling (ssmtp vs. postfix/exim/qmail/etc.)
Just free-flowing some thoughts as they come to me. I know some of this stuff, we all already know. #4. USE should only be what is set by the user themselves, otherwise empty. #5. I'm not sure if we actually need this or not. Do we need to add USE="bindist livecd" when doing GRP, or does our dep calculation not bother with --newuse? #6. PPC/Alpha support (I can help with this) #7. I think we should do some fun $foo with the kernel command line. Basically, we should determine which kernel we booted and with which options. We can do this by comparing /proc/cmdline with the contents of our various bootloader configs. Since there's already a "splash" checkbox, we can *always* throw those out unles someone checks the box, then *always* turn them on. Basically, this would give us a list of any non-default options that are used on the kernel command line, so if, like the reviewer we just read did, someone had to add noapic to their options to boot, the installer would automatically pass those to the bootloader, making it easier on the user. The best is to do this like we do "doscsi" so the user can remove them if they want. After all, some user might do "nox" or similar on the LiveCD, but not want that on their installed system. I'm sure I'll think of more stuff later, but this gives something to shoot for right now. Feel free to put your own ideas/suggestions here.
Wolf: for #7, just get me a list of args you'd want passed through to the grub conf and i'll get it done. i'm not sure i'd want to pass through nox.
Well, the problem is that a user can literally do hundreds of options. Any valid kernel option can be used, as well as the gernkernel/autoconfig options. I think it would be easier for us to keep an internal "blacklist" than it would be to whitelist what we do want. Does that make sense? Anyway... blacklist: root=.* init=.* dokeymap looptype=.* loop=.* cdroot initrd=.* nox splash=.* console=tty0 quiet (the last three should be enabled by checking the "splash" box, separately) That should cover everything, as most of the first part will be added later (if necessary) by the bootloader code.
Removing the dev-only restriction does not mean I'm opening this up for outside comments, that's what the -installer mailing list would be used for, instead.
first list: #1 has been completed. #2 is being put off until next release if being done at all. #3 is likely not going to be done. #4 has been done. #5 has also been accomplished. #6 (mta) done. second: #4 USE split done in gli-dialog. not in gtkfe yet. #5 no idea #6 andrew will work on alpha #7 the kernel args foo will not be done for this release. maybe next. so TODO: 1. Add support for kernelpkgs.txt to the installer... this file lists the packages in livecd-stage2 that were built against "livecd-kernel" allowing the user to get pre-compiled versions of external modules that may be required for them to have full functionality 2. USE should only be what is set by the user themselves, otherwise empty. also split into global and local USE screens. 3. I'm not sure if we actually need this or not. Do we need to add USE="bindist livecd" when doing GRP, or does our dep calculation not bother with --newuse? 4. PPC/Alpha support (I can help with this) 5. I think we should do some fun $foo with the kernel command line.
Remaining items: 1) kernelpkgs.txt support 2) pulling all user options from kernel commandline checking against an internal "blacklist"
The installer is deprecated.
