Bug 53185 - kde-i18n-* installed during upgrade
Summary: kde-i18n-* installed during upgrade
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: anaconda
Version: 7.3
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Matt Wilson
QA Contact: Brock Organ
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2001-09-04 23:00 UTC by csieh
Modified: 2007-04-18 16:36 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2001-09-05 19:07:55 UTC
Embargoed:


Attachments (Terms of Use)

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.



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