The glibc package contains ~8MiB+ of gconv converters that are loaded with dlopen. While it would be great to move all the converters to a table-drive approach, we might be able to reduce default container and install sizes by moving all the converters to a separate subpackage e.g. glibc-gconv to allow all removing all the converters by default. Installs that need the converters would install the glibc-gconv package. Internally we have many converters so we would not fail to convert from ASCII, and UTF-8.
Additional notes from today's review: The langpack files could have dependencies on the converters that are related to the charmaps used by the languages in the langpacks. This would help users get converters automatically installed for their systems. We would need to gather the list of charmaps used by languages and use that mapping to generate the dependencies. If you had only the minimal C/POSIX/C.UTF-8, then you don't need any installed converters because you are only using the ASCII and UTF-8 converters, which are both builtin. We should make ISO8859-1 (~18KiB), ISO8859-15 (~18KiB), UTF-7 (~26KiB), UTF-16 (~22KiB), and UTF-32 (~22KiB) should all be incrementally converted to internal converters to allow a minimum set of useful converters to always be available.
(In reply to Carlos O'Donell from comment #1) > Additional notes from today's review: > > The langpack files could have dependencies on the converters that are > related to the charmaps used by the languages in the langpacks. This would > help users get converters automatically installed for their systems. We > would need to gather the list of charmaps used by languages and use that > mapping to generate the dependencies. > > If you had only the minimal C/POSIX/C.UTF-8, then you don't need any > installed converters because you are only using the ASCII and UTF-8 > converters, which are both builtin. > > We should make ISO8859-1 (~18KiB), ISO8859-15 (~18KiB), UTF-7 (~26KiB), > UTF-16 (~22KiB), and UTF-32 (~22KiB) should all be incrementally converted > to internal converters to allow a minimum set of useful converters to always > be available. Alternatively, these could be glibc-gconv and the remaining converters could be glibc-gconv-extra. This way for minimal installations, one should not need any of the glibc-gconv packages. For desktop and/or server installations glibc-gconv could get pulled in and glibc-gconv-extra would have to be explicitly installed by users who need it.
There are some reviews of higher-level language APIs that we need to review: - PHP calls gconv and we need to see if things fail gracefully - Python 3 calls gconv and we need to see if things fail gracefully
This is now committed in rawhide. There are some gconv file handling cleanups that are awaiting upstream review. Once those are done, I'll backport all of those to F34.
FEDORA-2021-9ce0f65a09 has been pushed to the Fedora 35 stable repository. If problem still persists, please make note of it in this bug report.
Flipping this back to ASSIGNED as we wait for Fesco to review the sytem-wide change request: https://fedoraproject.org/wiki/Changes/Gconv_package_split_in_glibc
Dependency on glibc-gconv-extra has now been loosened.