Description of problem: X.org packages isn't possible select in 'Package Selection' menu, thus their selection should be depended at other packages selection, perhaps at selection some desktop WM and/or graphical applications. But it seems isn't true: my package selection section produced by s-c-k begins as: %packages @admin-tools @dial-up @directory-server @dns-server @editors @firefox @font-design @ftp-server @graphical-internet @graphics @hardware-support @legacy-network-server @legacy-software-support @mail-server @mate-desktop @mongodb @mysql @network-server @office @perl-web @php @printing @python-web @server-cfg @smb-server @sql-server @standard @system-tools @text-internet @web-server @window-managers @xfce-desktop ImageMagick ... but, as you can see, system-config-kickstart not add 'base-x' group there. After successful installation I had installed only these X.org packages: xorg-x11-apps-7.7-1.fc18.i686 xorg-x11-fonts-ISO8859-1-100dpi-7.5-6.fc18.noarch xorg-x11-fonts-misc-7.5-6.fc18.noarch xorg-x11-font-utils-7.5-10.fc18.i686 xorg-x11-server-common-1.13.2-2.fc18.i686 xorg-x11-server-utils-7.5-16.fc18.i686 xorg-x11-server-Xephyr-1.13.2-2.fc18.i686 xorg-x11-server-Xorg-1.13.2-2.fc18.i686 xorg-x11-xauth-1.0.7-2.fc18.i686 xorg-x11-xinit-1.3.2-7.fc18.i686 xorg-x11-xkb-utils-7.7-5.fc18.i686 (thanks to selected freenx-server, remmina-plugins-xdmcp, xfce4-session, lightdm, tigervnc-server-minimal packages,...), but not a single driver (xorg-x11-drv-*) module. Thus system was not starting to graphical interface. After installing 'base-x' group subsequently, thing works fine (for working plymouth would be perhaps necessary rebuild initramfs, but I even not use it). Version-Release number of selected component (if applicable): 2.9.0-1.fc18.noarch (build date Fri Feb 1 17:49:28 2013) Expected results: Necessary X.org packages (or base-x group) should be automatically selected, when are selected any graphical WMs. Additional info: Maybe better solution would be separate Xorg menu with optional package selection (+ dependency solving as above)
system-config-kickstart does not do any dependency solving; it never has. It's simply not that kind of program. If you require packages to be installed, you will need to select them in the interface yourself. There's definitely a valid use case for wanting to install all the programs, but not drivers (think: a headless system that people are running programs remotely from).
Created attachment 702902 [details] F17 s-c-k PkgSel screenshot show what not in F18 s-c-k But when s-c-k not trigger @base-x selection in dependency on some WMs selected, then s-c-k _should_ offer their selection, perhaps in separate submenu - as it was in previous releases (attached s-c-k-2.8.8-2.fc17.noarch screenshot offer 'X-Window System' submenu under 'Base System'. This submenu isn't present in s-c-k-2.9.0-1.fc18.noarch, thus isn't possible select its components).
Impossibility to select @base-x packages (as result of dependencies solving and/or manually) _is_ bug. Not sure when it is s-c-k bug, but can You eventualy assign it properly? Thanks.
All I can do here is set user visible groups to be displayed by default. But please keep in mind: comps has changed. Lots of things have changed. The current s-c-ks is provided only as a stop-gap for when I can fix things up more correctly. And I'm certainly not going to spent what little time I have talking about every single s-c-ks bug.
Please, take my experience with s-c-k only as effort for this tool be usefull, when already is there. For now I still live without problem with editing ks files manually. Thanks a lot.
I've changed it so invisible groups are displayed. They'll be under the Uncategorized environment on the left hand side.
This message is a reminder that Fedora 18 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 18. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '18'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 18's end of life. Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 18 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 18's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.