In Fedora 24, glibc will have the locales split into subpackages like: glibc-langpack-en-2.22.90-40.fc24.x86_64.rpm for English etc. See: https://bugzilla.redhat.com/show_bug.cgi?id=1238406 In Fedora 23, glibc-common contains all locales supporte by glibc. In Fedora 24, glibc-common will only contain the C.UTF-8 locale. That means, when only glibc and glibc-common are upgraded, the user will lose all locales except C/POSIX and C.UTF-8. As the user had all locales installed in Fedora 23, an upgrade should keep all locales installed. To do this, the upgrade needs to install the meta package "glibc-all-langpacks" which requires the packages glibc-langpack-* for all languages.
Isn't it possible to achieve the goal by using Obsoletes in your packages? I.e. have both glibc-common and glibc-all-langpacks declare something like: Obsoletes: glibc-common < 2.22.90-36
(In reply to Michal Schmidt from comment #1) > Isn't it possible to achieve the goal by using Obsoletes in your packages? > I.e. have both glibc-common and glibc-all-langpacks declare something like: > Obsoletes: glibc-common < 2.22.90-36 The Obsoletes capability is used usually when you rename a package or transition from one package to another. To be honest we'd like to avoid obscure poorly used and understood capabilities to implement core RPM packaging for Fedora. Therefore it's technically cleaner to do the upgrade once, install glibc-all-lanpacks once, and then never again. So such code would only ever live in the upgrade from F23 to F24 and be done once. It seems like a common use case to do 1 specific activity once during an upgrade from specific version X to Y. Does that make sense? Do we already have a place where we can add something like this in dnf system-upgrade?
I'll restate what I suggested on fedora-devel list: We have these days a capability for doing both strong and weak dependencies. My suggested approach would be to do this: * Have all langpack subpackages contain a virtual Provides: glibc-langpack * Have the main glibc package Requires: glibc-langpack and Suggests: glibc-all-langpacks If no specific package that Provides: glibc-langpack is part of the transaction, DNF will use the Suggests: to weight glibc-all-langpacks highest. This would mean that on upgrades (where only existing packages are part of the transaction), the Suggests would pull in the glibc-all-langpacks. It also means that later, you could manually remove any langpacks that you didn't want and it wouldn't break anything so long as at least one remains.
(In reply to Carlos O'Donell from comment #2) > The Obsoletes capability is used usually when you rename a package or > transition from one package to another. To be honest we'd like to avoid > obscure poorly used and understood capabilities to implement core RPM > packaging for Fedora. I don't think the use of Obsoletes for package splitting is obscure. yum was documented to work that way (http://yum.baseurl.org/wiki/YumPackageUpdates) and dnf behaves the same. > Therefore it's technically cleaner to do the upgrade > once, install glibc-all-lanpacks once, and then never again. So such code > would only ever live in the upgrade from F23 to F24 and be done once. It's technically cleaner to rely on the standard operation of the package manager. The Obsoletes can be removed in F26 when direct upgrades from F23 are no longer supported.
(In reply to Michal Schmidt from comment #4) > It's technically cleaner to rely on the standard operation of the package > manager. Agreed. I think Stephen's suggestion is the best way forward, but I'd like to keep this ticket open while I test it right now.
I think we both agree it should not be in logic of DNF nor dnf-system-upgrade plugin. Reassigning to glibc. (In reply to Stephen Gallagher from comment #3) > I'll restate what I suggested on fedora-devel list: > > We have these days a capability for doing both strong and weak dependencies. > My suggested approach would be to do this: > > * Have all langpack subpackages contain a virtual Provides: glibc-langpack > * Have the main glibc package Requires: glibc-langpack and Suggests:glibc-langpack > glibc-all-langpacks glibc-all-langpacks would need to provide `glibc-langpack` too, right? I am more inclined to Obsoletes solution as it's more clear - typical package splitting use case.
With glibc-2.23.90-3.fc25 and glibc-2.23.1-5.fc24 we have now fixed the issue in several important ways. The `glibc-all-langpacks` continues to be the correct way to get all locales, but now things are a bit smoother. (1) Virtual provides to make upgrade smoother. All glibc languages packs now provide `glibc-langpack`, that includes the glibc-all-langpacks (all language support). The core runtime depends on `glibc-langpack` and so when upgrading on systems without dnf, yum, or langpack plugin support, plain rpm dependency solving via suggests will install `glibc-all-langpack` for you and provide all the existing locales you previously had. This makes for a complete rpm solution with no other support required. This means that upgrading from a non-langpack supporting F23 to any future langpack supporting distribution will upgrade you to the newest set of supported locales. (2) Optimized "all languages" performance. In addition the `glibc-all-langpack` is optimized to again use the locale cache (locale-archive) to accelerate lookups for those users who prefer to have all languages installed. Previously we had `glibc-all-langpack` as a meta-package of all the other language packs, but that is no longer the case. (3) Provide glibc-minimal-langpack We add a minimal language pack that provides no languages. This allows you to install glibc-minimal-langpack and then uninstall glibc-all-langpacks and operate entirely under C, POSIX, and C.UTF-8 locales. This should resolve all problems that users have been seeing with the upgrade. Thank you for your patience. We really messed up here. In the future we'll make sure we cover all the upgrade cases more carefully. (4) Remove all languages to minimize installed size You can still minimize your installed size, but it's slighltly harder now. First you must install a valid language pack, and then remove `glibc-all-langpacks` to reduce the size of installed languages.