On 03/05/2016 07:13 PM, Dominik 'Rathann' Mierzejewski wrote:
On Sunday, 28 February 2016 at 23:31, Stephen Gallagher wrote:
>> On Feb 28, 2016, at 5:08 PM, Lars Seipel <lars.seipel(a)gmail.com> wrote:
>>> On Fri, Feb 26, 2016 at 08:56:27AM -0500, Stephen Gallagher wrote:
>>> Yeah, I think the best approach would be to have all the langpacks offer a
>>> virtual Provides: glibc-langpack and have the main package Requires:
>>> glibc-langpack and Suggests: glibc-all-langpacks.
>> This would force the installation of at least one langpack, no? The C,
>> POSIX and *C.UTF-8* locales are builtin, so for many systems it is very
>> reasonable to run without any language pack installed.
> Yeah, the workaround we're doing there is to have a glibc-minimal-langpacks
> subpackage that satisfies the requirement but contains no actual files.
> It's a bit of a hack, but not a particularly awful one.
Why a subpackage? Shouldn't the main glibc package (or glibc-common)
simply provide the C, C.UTF-8 and POSIX langpacks?
The glibc-common package *does* provide the C, C.UTF-8 and POSIX langpacks. The
reason for the subpackage is just a hack to fix some issues with upgrades.
We needed a way to ensure that upgrades would pull in the complete set of
langpacks, since we had no way of knowing which ones were actually being used.
The way we did this was to add a "Requires: glibc-langpack" to the glibc
and a "Suggests: glibc-all-langpacks" as well. Then we added "Provides:
glibc-langpack" to all of the subpackages that provide a language. However, this
resulted in not being able to restrict it to JUST the built-ins, so we added a
special, empty glibc-minimal-langpacks subpackage whose purpose is just to
satisfy the "Requires: glib-langpack" dependency. It contains no content and
doesn't add anything to the hard drive except the RPM database.