Bug 1812191

Summary:	glibc: [RFE] Split gconv into distinct subpackage.
Product:	[Fedora] Fedora	Reporter:	Carlos O'Donell <codonell>
Component:	glibc	Assignee:	Siddhesh Poyarekar <sipoyare>
Status:	CLOSED RAWHIDE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	rawhide	CC:	aoliva, arjun.is, codonell, dj, fweimer, law, mfabian, pfrankli, rth, siddhesh, sipoyare
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	glibc-2.33.9000-53.fc35	Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2021-08-10 13:48:05 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	1983145

Description Carlos O'Donell 2020-03-10 18:07:19 UTC

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.

Comment 1 Carlos O'Donell 2020-04-28 13:40:30 UTC

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.

Comment 2 Siddhesh Poyarekar 2021-01-19 03:49:22 UTC

(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.

Comment 3 Carlos O'Donell 2021-01-19 12:56:12 UTC

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

Comment 4 Siddhesh Poyarekar 2021-06-14 14:03:40 UTC

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.

Comment 5 Fedora Update System 2021-06-16 08:27:49 UTC

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.

Comment 6 Carlos O'Donell 2021-07-06 13:47:47 UTC

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

Comment 7 Siddhesh Poyarekar 2021-07-27 02:46:15 UTC

Dependency on glibc-gconv-extra has now been loosened.