> 1. Applying updates at install time is good. Randomly choosing a mirror > isn't, even if it gets lucky. > 1a. Threatening to give up if the mirror is a bit flaky is seriously bad > form. Several times it failed to fetch a package and proposed to reboot. > However, on retrying, the package was downloaded successfully. The one > package I investigated was an update, installing a local copy would have > been better even if out of date - a "yum update" at some time would fix > it. An option of "skip" would be good too, not every package is > critically important, and I could well do without gnome themese. Doing without packages could also be seen as bad form, and falling back to an older, local version could lead to a domino effect of dependencies. Not as easy to fix as it sounds. Of course the robustness could be better. I have not played with f12 in this respect, but in earlier releases anaconda was more prone to fail on ftp repos than on http ones (fewer retries if the repo was too busy), but required more manual input on http repos if there were problems. For FTP it just retried by itself, for http you had to klick in a dialog for each retry. I would say randomly choosing a mirror is good if it is robust enough to go on choosing new ones until it finds a stable one. > > Which brings me to > 2 Installing stuff I don't want. How hard must it be to do something > equivalent to a ubuntu "server" install, with absolutely no GUI stuff, > especially xorg GUI stuff with Gnome, KDE, XFCE and all the rest? Dependencies that lead to some packages having to split into non-gui and gui parts, I would guess? Perhaps also some apps need to have the stuff depending on gui bits moved into a plugin that could be packaged separately. I am not too worried about getting a load of X libraries and support files on a server, as I often need those anyway for tools that I run with remote display. On the other hand I agree that it should be possible to install a lean and clean server if I want to. We could call it - let's see - Fedora Core? :-D Regarding languages, I would also like to have the number of languages and input methods reduced to what I need. Why spend all that cpu and bandwith updating packages I will never need? Again, I suspect dependencies are the culprit. This is an issue on desktop systems as well as servers. On the other hand, I would like a group that would add all possible language support. There are lots of places where it is desirable to have absolutely all possible language support loaded by default. But not on servers... The other current discussion on increasing grub timeout is also something that is mostly needed on servers. My proposal would be that with only 'base' selected no gui stuff should get pulled in. Tall order, yes. Can it be done in time for F13? With only base, grub should present the good old menu with a 10 second timeout. Selecting any workstation-type group (gnome, kde, whatever) could then pull in a package that modifies grub config to the f12 default? -- fedora-test-list mailing list fedora-test-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list
