Multilib Middle-Ground

[Chris Snook]

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