Bug 1312956 - langpack split results in all locales being lost on update/upgrade
Summary: langpack split results in all locales being lost on update/upgrade
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: glibc
Version: 24
Hardware: All
OS: All
unspecified
urgent
Target Milestone: ---
Assignee: Carlos O'Donell
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: F24BetaBlocker
TreeView+ depends on / blocked
 
Reported: 2016-02-29 15:54 UTC by Adam Williamson
Modified: 2016-03-01 08:34 UTC (History)
14 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-03-01 08:34:33 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

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.


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