On 02/26/2016 10:39 AM, Zbigniew Jędrzejewski-Szmek wrote:
On Fri, Feb 26, 2016 at 08:56:27AM -0500, Stephen Gallagher wrote:
> On 02/26/2016 08:39 AM, Miroslav Suchý wrote:
>> Dne 26.2.2016 v 11:20 Carlos O'Donell napsal(a):
>>> No languages are available by default, we did this because otherwise
>>> you keep carrying forward locales that you can't remove.
>>
>> For this reasons we have weak dependencies. I guess that:
>> Recommends: glibc-all-langpacks
>> can do the work (install or by default, can be safely removed). Or
>> Suggests: glibc-all-langpacks
>> so it is not installed by default, but users can get the information that it can
enhance the usability of glibc.
>>
>
>
> 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. The net result would be that
> unless a specific langpack was chosen, you'd end up with all of them to satisfy
> the requirement. (This would also unbreak the upgrades without needing a patch
> to dnf system-upgrade)
That would be a much better solution. dnf-system-upgrade so far didn't
have any special handling for specific packages (except for a check
that the kernel is in the upgrade transaction) and there no mechanism
like this is implemented.
We are investigating switching to this. It shouldn't be a problem, and
with a quick rebuild of glibc in F24 I think we'll be ready. I just need
to run through the testing quickly on Monday.
All of our langpacks are auto-generated based on glibc supported locales
so there is no grunt work in changing, just testing again that it works
smoothly.
Cheers,
Carlos.