Bug 723796 - RFE: plugin for multilib protection of GTK modules
Summary: RFE: plugin for multilib protection of GTK modules
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: yum-utils
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Packaging Maintenance Team
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-07-21 07:52 UTC by Jens Petersen
Modified: 2018-07-18 21:32 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-07-18 21:29:54 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Jens Petersen 2011-07-21 07:52:30 UTC
Description of problem:
gtk does not handle missing multilib modules very gracefully.

For various kinds of gtk modules it would be very attractive
to handle the installation of multilib packages automatically
to avoid problems and enhance the users' multilib experience.

Steps to Reproduce:
1. install Fedora x86_64
2. install 32bit browser or other 32bit application
  
Actual results:
- no default gtk theme (uses gtk fallback)
- no gtk immodule for ibus installed
- missing other gtk modules for i686

Expected results:
- gtk modules to be available

Additional info:
Maybe something like yum-langpacks might be a good
starting point for this code, or maybe there is something closer?

Comment 1 James Antill 2011-07-21 13:18:47 UTC
 The first thing that comes to mind is ... why can't gtk use _isa on it's requires?

 langpacks is different, as what is wanted is defined by LANG= ... multilib isn't that big of a problem.

Comment 2 Jens Petersen 2011-08-04 05:49:54 UTC
Well the problem is the modules are optional packages,
and anyway this RFE is about matching gtk modules across multilib
not about direct dependencies.

So in ways this is actually similar to yum-langpacks.

Comment 4 Pravin Satpute 2016-05-25 06:39:25 UTC
Is this bug still exists?

Comment 5 Jens Petersen 2016-06-14 02:45:29 UTC
I believe so: though maybe it is less of a problem these days since 64bit 3rd party packages are the norm now perhaps.

Comment 6 Daniel Mach 2018-07-18 21:29:54 UTC
yum and related packages are no longer actively developed.
They are being replaced with dnf, dnf-utils, etc.

I'm closing this bug because it's most likely never going to be fixed.
If you still consider your bug report important, reopen it, please.

Comment 7 Daniel Mach 2018-07-18 21:32:57 UTC
yum and related packages are no longer actively developed.
They are being replaced with dnf, dnf-utils, etc.

I'm closing this bug because it's most likely never going to be fixed.
If you still consider your bug report important, reopen it, please.


Note You need to log in before you can comment on or make changes to this bug.