Glibc locale sub-packaging implementation options and associated issues

Fedora 23 schedule

Use folders for the locales instead of locale-archive.

Pros
- Makes the splitting much easier, no file conflicts
- No file conflicts
- No need to merge stuff into a locale-archive or delete it from there
- No problems with user defined locales, they are left alone as long as their folder does not have exactly the same name as a system locale
- Easier to use with an xdg-app runtime: https://lists.fedoraproject.org/pipermail/devel/2015-June/211630.html
- User locales and system locales can be mixed using LOCPATH
Cons
- More stats and mmaps when an application starts: If a locale-archive is used, only that file is opened and mmapped. With the folder structure, around 15 files/folders are tried to open and 13 small LC_* files are mmapped instead of mmapping only one huge locale-archive file. For a small program like “date” which does not do much and is dominated by startup time, this makes it run twice as slow.

Package binary blobs and merge into/delete from locale-archive

Pros
- No slowdown at runtime, only locale-archive is opened and mmapped
Cons
- Will not work well with deltarpm: https://lists.fedoraproject.org/pipermail/devel/2015-June/211623.html. When the binary stuff in the sub-packages is deleted after the content is merged into locale-archive, the sub-packages are incomplete and deltarpm needs a complete local rpm to build an update using a binary diff.
- If the binary stuff in the sub-packages is not deleted after merging into locale-archive, it wastes a lot of disk space.
- User locales and system locales *cannot* be mixed using LOCPATH (If the user creates his own locales in some folder with localedef and then uses LOCPATH to point to the folder, fallback to system locales which do not exist in that folder does not work)

Generate using localedef, don’t package binary locales (like Debian/Ubuntu)

Pros
- No slowdown at runtime if locale-archive is used
  - (One could use a folder structure with this approach as well (as in Method 1), if one wants to make it possible to mix user locales in LOCPATH with system locales)
- sub-packages are very small, they contain no binary data, only the very small sources are needed (/usr/share/i18n/locales/ is only 6.6MB for all locales)
- Should work well with user locales. Ubuntu has a folder with small files containing lists of locales to generate (not a huge single file anymore). Subpackages can add/remove files to that folder, then call locale-gen in %post and %postun.A user would just add his own locale sources to /usr/share/i18n/locales/ and a file with the list of locales to generate to the folder checked by locale-gen
Cons
- Generating locales takes a lot of time. This does not seem to be as bad as I first thought though because one can often prevent generating again on updates if nothing relevant has changed. With some checksums and a list of dependencies of the locales one can check whether anything relevant has changed and skip the generation if not. The Debian/Ubuntu generation script seems to partly achieve that although it does not seem to work always.