Bug 1380069 - glibc-langpacks-<local_code> is not remove with dnf remove langpacks-<local_code>
Summary: glibc-langpacks-<local_code> is not remove with dnf remove langpacks-<local_c...
Status: NEW
Alias: None
Product: Fedora
Classification: Fedora
Component: glibc (Show other bugs)
(Show other bugs)
Version: 28
Hardware: Unspecified Unspecified
unspecified
medium
Target Milestone: ---
Assignee: Carlos O'Donell
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Keywords: Reopened
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-09-28 15:32 UTC by Quentin Tayssier
Modified: 2018-12-06 14:24 UTC (History)
18 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
: 1644704 (view as bug list)
Environment:
Last Closed: 2017-12-12 10:07:31 UTC
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)
debugdata from dnf remove langpacks-fr --debugsolver (468.37 KB, application/x-gzip)
2016-09-29 06:01 UTC, Quentin Tayssier
no flags Details

Description Quentin Tayssier 2016-09-28 15:32:33 UTC
Description of problem:

glibc-langpack-<local_code> are not remove when you use dnf remove langpacks-<local_code>

Version-Release number of selected component (if applicable):

dnf 1.1.10

How reproducible:
always

Steps to Reproduce:
1. dnf install langpacks-<locale_code>
glibc-langpack-<local_code> is installed
2. dnf remove langpacks-<locale_code>

Actual results:
glibc-langpack-<local_code> is not remove

Expected results:
all langpacks-<local_code> package installed with dnf install langpacks-<local_code> should be remove.

Additional info:
https://fedoraproject.org//wiki/Changes/Glibc_locale_subpackaging

If i try to remove manually glibc-langpacks-<locale_code> there is a lot of package that should be remove also like anaconda and other langpacks that i want to keep.

Try with langpacks-fr and langpacks-ja

Comment 1 Igor Gnatenko 2016-09-28 15:37:19 UTC
Run removal with --debugsolver and attach debugdata directory.

Comment 2 Quentin Tayssier 2016-09-29 06:01 UTC
Created attachment 1205811 [details]
debugdata from dnf remove langpacks-fr --debugsolver

Comment 3 Igor Gnatenko 2016-09-29 06:15:24 UTC
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.

Comment 4 Carlos O'Donell 2016-09-29 14:02:23 UTC
(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.

Comment 5 Igor Gnatenko 2016-09-29 14:57:32 UTC
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.

Comment 6 Carlos O'Donell 2016-09-29 15:12:39 UTC
(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).

Comment 7 Florian Weimer 2016-09-29 18:34:23 UTC
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.

Comment 8 Igor Gnatenko 2016-10-03 11:17:52 UTC
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.

Comment 9 Mike FABIAN 2016-10-04 05:41:25 UTC
(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.

Comment 10 Couret Charles-Antoine 2017-09-19 17:10:09 UTC
The issue still happen (i18n test day today for F27!).

Comment 11 Fedora End Of Life 2017-11-16 18:49:35 UTC
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.

Comment 12 Fedora End Of Life 2017-12-12 10:07:31 UTC
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.

Comment 13 Fedora End Of Life 2018-02-20 15:22:39 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 28 development cycle.
Changing version to '28'.

Comment 14 Couret Charles-Antoine 2018-03-15 21:34:17 UTC
The issue still happen (i18n test day for F28).

Comment 15 Couret Charles-Antoine 2018-09-04 21:33:31 UTC
The issue still happen (i18n test day for F29).

Comment 16 Michael Erwin 2018-10-03 14:58:58 UTC
The issue still occurs with F29 Beta 1.5 + with updates


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