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-chive or delete it from there
- No problems with usr define 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)