Changes/Glibc locale subpackaging

Glibc locale subpackaging

Summary

This change should make it possible to install or uninstall locales individually.

Owner

• Name: Mike Fabian, Siddhesh Poyarekar, Carlos O’Donell
• Email: <mfabian At redhat DOT com>, <spoyarek AT redhat DOT com>, <codonell AT redhat DOT com>
• Release notes owner:

Current status

• Targeted release: Fedora 23
• Last updated: (2015-06-17)
• Tracker bug: <will be assigned by the Wrangler>

Detailed Description

Currently the file /usr/lib/locale/locale-archive contains all locales and is thus huge (103MB).

For small systems (and containers) it would be useful to be able to install only a small number of locales.

Recently we made it possible to install a small number of locales by supplying the rpm-macro “_install_langs”, for example

   rpm -i -D _install_langs="en:de_DE" glibc-common.rpm

will install all English locales and all German locales which start with “de_DE”,

   rpm -i -D _install_langs="en_US.utf8" glibc-common.rpm

will install only the en_US.utf8 locale,

   rpm -i -D _install_langs="POSIX" glibc-common.rpm

will install nothing (but the POSIX/C is still available because it is builtin into glibc).

But this approach works only during an Anaconda based install when Anaconda supplies the _install_langs rpm-macro.

When glibc is updated later, the _install_langs macro will not be supplied on the command line during the update and the default value “all” of “_install_langs” from /usr/lib/rpm/macros will be used and all locales come back during an update.

Therefore, this solution is far from perfect.

It should be made possible to install and uninstall locales individually, for example by having a separate package for the locales for each language. Installing such a package would add these locales to locale-archive, uninstalling it would remove them.

Anaconda then needs to be changed to handle such language packages.

Benefit to Fedora

This change should make it possible to reduce the minimum size of an installation considerably.

Scope

• Proposal owners:

   1. Figure out the best approach to to install/uninstall locales
   2. Make sure that locales added manually by the user are not destroyed (currently they are lost when glibc is updated)
   

• Other developers:

Anaconda needs to be made aware of the new approach to handle installation/uninstallation of locales

• Release engineering:

I am not sure whether this has affects release engineering, probably the packages in the install image change when parts are split out of glibc-common.

• Policies and guidelines:

No, this change does not require updates to policies and guidelines.

• Trademark approval: not needed for this Change

Upgrade/compatibility impact

The user should not notice any change after the update. All locales which were installed before should still be installed after the update.

After the update it should be possible to uninstall locales for unneeded languages but this is optional.

How To Test

• Try to install/uninstall packages containing locales for some languages.

• Check with “locale -a” whether the locales for these language have been correctly installed or uninstalled.

• Make sure that other locales, especially custom locales added by the user, are not affected.

User Experience

It should be possible to save disk space by having fewer locales installed.

Dependencies

• Anaconda
• dnf-langpacks

Contingency Plan

• Contingency mechanism: Revert changes to glibc packaging
• Contingency deadline: Before F23 Beta release eg. Beta freeze.
• Blocks release? No
• Blocks product? No

Documentation, notes

• QA and validation
  • Validated binaries and files should be downloaded and installed.
  • No slow compilation should happen on the host.
  • For RHEL we want to be able to QA the binary artifacts and ship those. Shipping and compiling from source files is not an option we should consider.

• Compatibility with locale-gen:

• • Strong consideration should be given to writing a dummy wrapper that

  provides as much functionality from locale-gen as possible but
  uses yum install foo in the background to meet the requirements.

• • This helps users transition packages from debian/ubuntu to Fedora.
  • For example /etc/locale.gen could be parsed and appropriate packages

  installed to cover the set of locales requested, or with a 1:1 mapping
  (lots of locale sub-packages) it would be trivial.

• • Update of glibc could run locale-gen wrapper.
  • Avoid using locales sub-package except to install common locale support

  files and binaries. Ubuntu uses locales package for this purpose, but
  provides language-pack-* for languages (like Windows)

• Simple for the user to understand.

 - Users should install "English" or "German" not "en_US.UTF-8".
 - Users know what languages they need but shouldn't care about
   codesets or any other factors.

 - Exmpale: yum install en-locales;

- Either en-locales is a meta-package that insatlls all of the english locales, or is a package that contains all the english locales. - Probably 217 packages if we split it by lang name before underscore, but that would be way too much. We run into political issues with package counts.

 - Example: vi /etc/locale.gen; locale-gen;

- locale.gen must support simple "en" or "de" lines to install all formats of english or german.

 - Example: yum install locale-source;

- Installs locale source files.

 - Example: yum install all-locales;

- Install all binary locales. No locale may be called "all" (same restriction as build-locale-archive). - Includes installing a other-locales package which contains anything not split out. Adds limit that no locale may be called "other".