Johns thoughts on F13

[birger]

> 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?