Bug 1312103 - “dnf system-upgrade” needs to install “glibc-all-langpacks” when upgrading from f23 to f24
“dnf system-upgrade” needs to install “glibc-all-langpacks” when upgrading fr...
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: glibc (Show other bugs)
23
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Carlos O'Donell
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2016-02-25 13:03 EST by Mike FABIAN
Modified: 2016-03-01 03:29 EST (History)
16 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-03-01 03:29:06 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Mike FABIAN 2016-02-25 13:03:53 EST
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.
Comment 1 Michal Schmidt 2016-02-26 08:07:02 EST
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
Comment 2 Carlos O'Donell 2016-02-26 09:11:13 EST
(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?
Comment 3 Stephen Gallagher 2016-02-26 09:17:06 EST
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.
Comment 4 Michal Schmidt 2016-02-26 09:37:32 EST
(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.
Comment 5 Carlos O'Donell 2016-02-26 09:46:56 EST
(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.
Comment 6 Honza Silhan 2016-02-29 11:18:25 EST
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.
Comment 7 Carlos O'Donell 2016-03-01 03:29:06 EST
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.

Note You need to log in before you can comment on or make changes to this bug.