Warren Togami wrote:
Bill Nottingham wrote:
Warren Togami (wtogami@xxxxxxxxxx) said:
* In the case of this scim change: You do a Korean language install.
Even on a non-LiveCD install you end up missing i386 (and font) packages
necessary for full Korean desktop support. There is no obvious way for
the user to know why it broke. It is suddenly impossible to have a full
Korean language desktop install by using the yum group. THIS IS A BIG
PROBLEM OUTSIDE OF LIVECD.
... 'and font'? The scim change changes fonts? O RLY?
This is *exactly* what I said. You're saying we should do something
special for an input method (for GTK only) that we don't do for QT
input methods, NSS modules, PAM modules, etc.
Then I guess we are really not that much worse off. It is impossible
for yum groupinstall to "fix" these problems in Fedora 9.
This points to a more general problem: We were not happy with having a
huge pile of unnecessary i386 packages so our solution was to completely
eliminate them from the default install. We went TOO FAR
overcompensating for the previous broken multilib behavior.
Dependencies or a comps multilib whitelist could be a nice
middle-ground. Some users want to be i386-free. Other users want a
tiny set of expected packages to be multilib to avoid confusion. The
current yum option is either all or none.
Perhaps we need a third option like "smart" which uses a multilib
whitelist that can be updated via repodata. Anaconda and other GUI
interfaces can allow the user to choose between "smart" and "100% i386
free". This way "yum groupinstall korean-support" can install
everything the user expects.
This avoids the lose of:
- expecting the user to manually install a complicated set of
arch-specific packages because they can't use yum groupinstall
- expecting the user to change the yum multilib priority option and
subject themselves to a huge pile of unnecessary crap that they will
never need.
No time to do this before F9.
Warren Togami
wtogami@xxxxxxxxxx
Perhaps we need to think about packaging policies in a more associative way,
rather than a hierarchical way. The package groups make sense for a lot of
things, but they aren't very good at describing sets of packages, such as
libraries and devel packages, that span the entire distribution. I'd love to
see a screen with a half-dozen or so toggles early in the installer with
switches such as these:
[X] Install 32-bit libraries
This will increase the size of the installation and the time required to
download software updates, but will also make it more convenient to install
applications not included in Fedora. These libraries can also be installed
later using yum or PackageKit. If you are using a system with a slow internet
connection or a small hard drive, you may want to disable this.
[ ] Install development headers
This will increase the size of the installation and the time required to
download software updates, but will also make it more convenient to compile
applications from source code. These headers can also be installed later using
yum or PackageKit. If you plan to use the system for software development, it
may be convenient to enable this.
We could even have these switches affect the final yum configuration, perhaps
through selection of packages such as yum-basearchonly. The switch screen would
also be a good place to ask a few questions to distinguish between power users
and newbs, so we could improve general usability without interfering with the
way the developers and testers (our most important users) work. Obviously this
is not F9 stuff, but something to think about as we look to the future and think
about high-level usability.
-- Chris
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
