Bring back configurability in expert mode

Jef Spaleta jspaleta at princeton.edu
Thu Jul 24 20:12:05 UTC 2003


Jack Bowling wrote, somewhere in the digest:
>[snip]
>> Leave the dummy installer in RHEL and give those who want the 
>> > "expert" mode exactly what they want in RHLP's installer.
>> 
>> And maintain two installers?  That sounds like a horrible waste of
>> already limited resources.

>Indeed it does. Which is why it will hopefully be coded up by somebody
>ex-RH under the upcoming RHL regime.  Then they can maintain it
>themselves and only have it vetted through you. Or is that not how
>things are supposed to work soon?

Bah thats still a waste...yer just adding extra resource to create
multiple codebases...instead of using that extra resources to come to a
reasonable agreement as to how to tackle ALL the competing interests
sorrounding installs in a sane, logical way. I'd much rather get an
external developer on board to fix something like r-c-p or firstboot to
enhance the post-install process to recover and surpass the flexibility
that use to be in the installer.  There needs to be a reasonable
development direction that the development community basically agrees to
walk down together. Competing installer bases...wasteful, and should be
avoided inside this project.

I'd much rather focus any external developer time...on sane default
groups and a sane 'minimal' mode that can be booted into to continue
detailed package installation, from say external yum repos...in one-off
installs(where as kickstart is clearly the way to go for large
replication installs.) Hell i say take this package selection stuff out
of the installer as much as you can...and make a minimal base install
the default, with a nice featurerich firstboot environment. is it really
a good idea to do as much as the installer is doing from the cdrom
ramdisk environment? is the complexity of the installer affecting the
minimal hardware requirements needed to do an install? I for one, find i
need to be much more picky about what i'm installing, on older systems
becuase of resource constraints...and if streamlining the installer
process and ripping out as much of the package management logic from it
as can be moved into a firstboot situation helps with lower the required
hardware specs for an install, that would make some sense to me and
provides more value to me than a complicated package selection process
during the cdrom install.

-jef"RFE:yum repos as native anaconda install media option"spaleta





-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-test-list/attachments/20030724/aadd0e74/attachment.sig>


More information about the fedora-test-list mailing list