Bug 1380069

Run removal with --debugsolver and attach debugdata directory.

Created attachment 1205811 [details]
debugdata from dnf remove langpacks-fr --debugsolver

This is bug in glibc packaging.

glibc:
Requires: glibc-langpack

glibc-all-langpacks:
Provides: glibc-langpack

glibc-langpack-fr:
Provides: glibc-langpack


This is since https://github.com/openSUSE/libsolv/commit/4e245d61daa731ebab0ac7e0f7bd87ba6c63f116.

(In reply to Igor Gnatenko from comment #3)
> This is bug in glibc packaging.
> 
> glibc:
> Requires: glibc-langpack
> 
> glibc-all-langpacks:
> Provides: glibc-langpack
> 
> glibc-langpack-fr:
> Provides: glibc-langpack
> 
> 
> This is since
> https://github.com/openSUSE/libsolv/commit/
> 4e245d61daa731ebab0ac7e0f7bd87ba6c63f116.

Could you please explain why this is a bug in glibc packaging?

glibc:
Requires: glibc-langpack = %{version}-%{release}
Suggests: glibc-all-langpacks = %{version}-%{release}

glibc-all-langpacks:
Provides: %{name}-langpack = %{version}-%{release}

glibc-langpack-fr:
Provides: %{name}-langpack = %{version}-%{release}

Thus if you remove glibc-langpack-fr (your only language pack) you must install something that provides glibc-langpack (virtual) and that something _should_ be glibc-all-langpacks as it's suggested by glibc.

You must have _some_ language packs installed for your system to work, either:
glibc-minimal-lanpack
glibc-all-langpacks
or
<Some installed langpack>

This seems more like a libsolv issue in that it has become overly cautious about removing providers, which is wrong. You only need one provider to satisfy the requirements, and that should be a minimal install, and that should be what is produced. If users are having the wrong provider removed when two similar providers exist, _that_ is a packaging problem.

I'm looking to the dnf team for guidance on this.

Basically libsolv doesn't know what's the better provider of 'glib-langpack', so it keeps all of them.

I think changing Req: glibc-langpack + Sug: glibc-all-langpacks to Req: glibc-all-langpacks is the proper fix.

(In reply to Igor Gnatenko from comment #5)
> Basically libsolv doesn't know what's the better provider of
> 'glib-langpack', so it keeps all of them.

It does know. The package with the require gave a suggestion. Use the suggestion.
 
> I think changing Req: glibc-langpack + Sug: glibc-all-langpacks to Req:
> glibc-all-langpacks is the proper fix.

This is not an acceptable fix.

The point of the glibc changes is to minimize localization information for cloud and containers, we do not want to force all locales to be installed anymore, not even on a desktop (which could be a minimally sized VM).

In an era where storage costs money on a monthly basis, we want to make sure our installs are as small as possible.

Your suggested fix of making glibc-all-langpacks required will install the +180MB "all languages" sub-package for _all_ fedora users, and this is unacceptable.

Fundamentally the user has requested that langpack-fr removed, and dnf has failed to do that because it is being overly cautious. This needs to be fixed, not glibc.

I'm reassigning to dnf. I have not seen a technical argument for why libsolv has to be made so cautious that it stops honouring user requests to remove packages (that have multiple providers).

Could we use

Requires: (glibc-all-langpacks or glibc-langpack)

instead?  Would DNF do the intended thing?

The problem is that rich/boolean dependencies in Requires:/Recommends: are still banned by the packaging guidelines.

glibc-all-langpacks does not require any of langpacks (it just contains 2 files: /usr/lib/locale/locale-archive, /usr/lib/locale/locale-archive.tmpl).

Suggests is something to make favorite one implementation over the another, but it doesn't mean it has some real preference for providing.

Imagine:

# Pkg: systemd
# Req: libsqlite.so.0

# Pkg: sqlite3
# Prv: libsqlite.so.0

# Pkg: hipchat
# Prv: libsqlite.so.0

What should happen for "dnf autoremove"? It can safely remove "sqlite3" and your system will be broken due to wrong packaging.

(In reply to Igor Gnatenko from comment #8)
> glibc-all-langpacks does not require any of langpacks (it just contains 2
> files: /usr/lib/locale/locale-archive, /usr/lib/locale/locale-archive.tmpl).

The locale information from all langpacks combined
is in this locale-archive database. This is a more compact and slightly faster
format than the format used in the individual langpacks. That means, if you need
very many or maybe even all languages, it is better to install glibc-all-langpacks. If you need only a few languages, it is better to install only  the individual langpacks for the languages you really need.

The issue still happen (i18n test day today for F27!).

This message is a reminder that Fedora 25 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 25. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '25'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 25 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged  change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

Fedora 25 changed to end-of-life (EOL) status on 2017-12-12. Fedora 25 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

This bug appears to have been reported against 'rawhide' during the Fedora 28 development cycle.
Changing version to '28'.

The issue still happen (i18n test day for F28).

The issue still happen (i18n test day for F29).

The issue still occurs with F29 Beta 1.5 + with updates

(In reply to Florian Weimer from comment #7)
> Could we use
> 
> Requires: (glibc-all-langpacks or glibc-langpack)
> 
> instead?  Would DNF do the intended thing?

Could we do this for F31?

This seems like a good approach to me.

What if we change the glibc base package

  from "Requires: glibc-langpack = %{version}-%{release}" to "Recommends: glibc-langpack = %{version}-%{release}"

(or maybe could even just directly "Recommends: glibc-all-langpacks = %{version}-%{release}"),

and just get rid of glibc-minimal-langpack?

This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle.
Changing version to '31'.

This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle.
Changing version to 31.

This bug appears to have been reported against 'rawhide' during the Fedora 32 development cycle.
Changing version to 32.

This bug appears to have been reported against 'rawhide' during the Fedora 33 development cycle.
Changing version to 33.

This bug appears to have been reported against 'rawhide' during the Fedora 34 development cycle.
Changing version to 34.

Still there for F39