Bug 1312103

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.