On Wed, 2005-09-21 at 14:45 +1000, Alan Milligan wrote: > Jeremy Katz wrote: > > Unfortunately, this would not be the desired behavior of other people. > > So as it stands, we're going to stick to requiring the kickstart config > > to be specified. > This typical RH response hightlights the fundamental flaw in Fedora and > needs to change if this platform is going to have any relevance as the > Linux user community's expectations evolve upward. Huh? I think plenty of things are changing, but you can't just always change everything. Maybe it's just that it's 3 am and I really shouldn't reply to mail this late. > Community users are clearly indicating that they'd like a generalised > installer as we all have many and varied uses for Linux - quite often > outside the norm - RH's norm at least. And I think anaconda goes a long way here. At the same time, some constraints have to be made around things. Otherwise, you end up with tons of options that are confusing, untested and fragile. So there's the ever-present trade-offs which must be made between flexibility and usability. One of the ways that we approach this is by making some things only available via kickstart. Another is by trying to improve the default user's install path so they don't have to deal as much with the things which are confusing (eg, partitioning). > Why can't we consider adding another input parameter to the > anaconda-runtime suite to package a default kickstart into an image. > Most people won't use this and they will still enjoy the status quo. This is something entirely different, and I would be all for having a script available to embed a ks.cfg into a boot image. Those are the sorts of things that do provide benefit for the user who has a better idea of what they're doing. One downside, though, is discoverability. Hopefully, starting to have a more concrete location for people to start looking for information as well as adding their own tips and tricks will help[1] > Those of who would like this feature would love to contribute the code > even - if only we could ... Patches accepted[2] and I'd love to get more of them. > P.S. I too very strongly support URLGrabber into anaconda!!! urlgrabber being used for the second stage only helps with a subset of things. Mostly it makes things easier for us as we get to deal with a consistent API instead of the inconsistency of urllib2. To be able to really take advantage of some of the nicer things like proxy support, some code will also need to be written for the loader. Jeremy [1] So I haven't really said much about http://fedoraproject.org/wiki/Anaconda here. At the moment, it includes a migration from the wiki which Alexander Rau set up as well as the start of some structure for more information. If you're interested in adding content, create a wiki user and ask for edit access and that should be able to be arranged [2] Just because they're welcomed doesn't mean that I'm going to just take anything -- I do tend to have comments on non-trivial patches just for style or to fit in better with future changes[3] [3] eg, the changes I suggested for the nfs mount options patch
