[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Multilib Middle-Ground



Warren Togami wrote:
Bill Nottingham wrote:
Warren Togami (wtogami redhat com) 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 redhat com


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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]