Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 53185

Summary:	kde-i18n-* installed during upgrade
Product:	[Retired] Red Hat Linux	Reporter:	csieh
Component:	anaconda	Assignee:	Matt Wilson <msw>
Status:	CLOSED NOTABUG	QA Contact:	Brock Organ <borgan>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	7.3	CC:	bero
Target Milestone:	---
Target Release:	---
Hardware:	i386
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2001-09-05 19:07:55 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description csieh 2001-09-04 23:00:14 UTC

From Bugzilla Helper:
User-Agent: Mozilla/4.77 [en] (X11; U; Linux 2.4.3-12 i686)

Description of problem:
most of the kde-i18n-*  rpms are installed during a upgrade install from
RedHat 6.1 even though they were NOT installed prior .

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1.Install RedHat 6.1(probably fails with 6.2 and 7.0 too) including kde
2.select upgrade 
3.
	

Actual Results:  you end up with most of the kde-i18n-* which totals about
120MB

Expected Results:  Maybe got one specific to what language I have already
chosen,  but not all of them.

Additional info:

This happens on 7.1 too.

Comment 1 Michael Fulbright 2001-09-05 16:00:45 UTC

Matt, Bero - any idea what is pulling these packages in? Is it just to satisfy
the base kde requirements?

Comment 2 Bernhard Rosenkraenzer 2001-09-05 16:07:15 UTC

They aren't pulled in to fulfill a base dependency - my home system doesn't 
have any *i18n* packages installed.

The problem is probably the following:
In the days of KDE 1.x, the translations were maintained in the package trees 
themselves, so e.g. kcontrol.mo was in kdebase.

In KDE 2.x, kde-i18n has been moved to a separate tree to save users from 
having to install all locales and to make the translators' work easier.

Now anaconda detects kcontrol.mo was installed and is no longer present, and 
that the file is provided by the new package kde-i18n-{all languages supported 
by KDE 1.x here}, and therefore installs the package.

Guess the fix is to exclude /usr/share/locale from the search for current 
packages obsoleting old ones.

Comment 3 csieh 2001-09-05 19:07:50 UTC

Is it possible for the installer to "mention" why the package is being
upgraded/installed during the upgrade.  I noticed that some messages about
dependencies go to alt-f3 but they scroll off the screen and are lost.

Things like 

	dependent on package <  >
	dependent on file/directory <>
	upgraded because of new version <>
	etc	

Thanks

-connie sieh

Comment 4 Matt Wilson 2001-09-05 20:19:54 UTC

the upgrade algo is doing the right thing.  You had packages installed that
owned files in /usr/share/locale/.  Upgrading those packages result in those
files going away.  The upgrader finds where the files went and adds the packages
that now hold the files.