Bug 1312956

Summary:	langpack split results in all locales being lost on update/upgrade
Product:	[Fedora] Fedora	Reporter:	Adam Williamson <awilliam>
Component:	glibc	Assignee:	Carlos O'Donell <codonell>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	urgent	Docs Contact:
Priority:	unspecified
Version:	24	CC:	arjun.is, codonell, dj, fedora, fweimer, jakub, law, mfabian, pfrankli, pnemade, robatino, sgallagh, siddhesh, zbyszek
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	All
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2016-03-01 08:34:33 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	1230433

Description Adam Williamson 2016-02-29 15:54:05 UTC

The glibc langpack split was implemented in such a way that people with Fedora 24 or Rawhide installs who updated their systems in the usual way lost all their locales.

This leads to various other bugs, e.g. gnome-terminal failing to start up and ssh failing to work. Realistically, though, I don't think we can call all of those cases bugs and say everything has to work with C locale, it's been expected for years that appropriate locales for the system will be available and at least in the short term we need to make sure they still will be.

I'm nominating this as a Beta blocker, per criteria "For each one of the release-blocking package sets, it must be possible to successfully complete a direct upgrade from fully updated installations of the last two stable Fedora releases with that package set installed... The upgraded system must meet all release criteria." (Beta) and "It must be possible to run the default web browser and a terminal application from all release-blocking desktop environments." (Alpha) - upgraded systems will not "meet all release criteria" since GNOME Terminal will not launch.

Comment 1 Florian Weimer 2016-02-29 16:01:33 UTC

Is this something that fedup could address?

Comment 2 Stephen Gallagher 2016-02-29 16:06:30 UTC

(In reply to Florian Weimer from comment #1)
> Is this something that fedup could address?

We already have a fix for this being tested in glibc. It's being fixed by appropriate Requires, Provides and Suggests in the spec file.

Comment 3 Adam Williamson 2016-02-29 16:35:57 UTC

fedup doesn't exist any more, either, so no. :)

Comment 4 Carlos O'Donell 2016-02-29 18:38:37 UTC

(In reply to Adam Williamson from comment #3)
> fedup doesn't exist any more, either, so no. :)

Sure, dnf system-upgrade :-}

Comment 5 Zbigniew Jędrzejewski-Szmek 2016-02-29 18:45:53 UTC

> Realistically, though, I don't think we can call all of those cases bugs and say everything has to work with C locale

I don't think it reasonable to require locales to be always installed. For most packages silently continuing without any translation is the right thing to do. There may be exceptions, like software which outputs financial numerical data and is useless/misleading without i18n. But gnome-terminal doesn't fall into this category. Crashing on missing locales is simply a bug in gnome-terminal and should be fixed there.

(This is not to say that glibc might not want to install more locales on upgrade.)

> Is this something that fedup could address?

It would be really terrible if dnf system-upgrade had to grow those kinds of hacks. So far it hasn't any. This allows it to remain simple to implement and understand. In fact the only package-specific logic that dnf system-upgrade has is for the kernel, and even that is a source of problems, and something that will hopefully be removed.

Comment 6 Adam Williamson 2016-02-29 19:06:18 UTC

I should have said realistically in the short term. Maybe it's an interesting exercise for someone to go through a bunch of apps and find ones that don't work without locales and fix them, but for practical purposes for Fedora 24, the sensible thing to do is make sure locales are available in the situations where they've always been available before and we don't have any urgent need to get rid of them.

Comment 7 Carlos O'Donell 2016-02-29 19:14:03 UTC

(In reply to Adam Williamson from comment #6)
> I should have said realistically in the short term. Maybe it's an
> interesting exercise for someone to go through a bunch of apps and find ones
> that don't work without locales and fix them, but for practical purposes for
> Fedora 24, the sensible thing to do is make sure locales are available in
> the situations where they've always been available before and we don't have
> any urgent need to get rid of them.

We do have an urgent need to get rid of them, but it's entirely in another use case. So I agree with you 100% on the solution, the glibc team will make sure that by default the upgrade, dnf system-upgrade, and other various upgrades (when no language is selected via langpacks) produce the same system you had before the upgrade.

Comment 8 Adam Williamson 2016-02-29 19:16:01 UTC

"We do have an urgent need to get rid of them, but it's entirely in another use case."

Right, that's what I meant by "the situations where...we don't have any urgent need to get rid of them". :)

Comment 9 Carlos O'Donell 2016-03-01 08:34:13 UTC

With glibc-2.23.90-3.fc25 and glibc-2.23.1-5.fc24 we have now fixed
the issue in several important ways.

See:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/WXOOUGA3YCB2O4O77JGLSJZ25BS4RFK5/

Upgrades now properly install glibc-all-langpacks and preserver the "all languages installed" behaviour by default.