Hide Forgot
+++ This bug was initially created as a clone of Bug #1319073 +++ I used Fedora-Workstation-Live-x86_64-24_Alpha-5.iso and installed it in qemu. I selected Japanese in the language selection of the installation. I added an US English keyboard layout and made it the first priority. After the installation started, I entered a password for root but created no user. After reboot, in gnome-initial-setup, I selected German as the language. After the setup was finished and gnome started, I found that the following glib packages were installed: [mfabian@localhost ~]$ rpm -qa | grep glibc glibc-common-2.23.1-5.fc24.x86_64 glibc-langpack-en-2.23.1-5.fc24.x86_64 glibc-2.23.1-5.fc24.x86_64 glibc-headers-2.23.1-5.fc24.x86_64 glibc-devel-2.23.1-5.fc24.x86_64 glibc-2.23.1-5.fc24.i686 glibc-all-langpacks-2.23.1-5.fc24.x86_64 [mfabian@localhost ~]$ If glibc-all-langpacks is installed, then glibc-langpack-en is redundant and only wastes disk space because glibc-all-langpacks already contains all the locales, including the English locales. And why glibc-langpack-en if the installation was done in Japanese? Shouldn't it rather be glibc-langpack-ja then? --- Additional comment from David Shea on 2016-03-18 11:24:02 EDT --- Please attach the logs from /var/log/anaconda. --- Additional comment from David Shea on 2016-03-18 11:29:37 EDT --- Oh, hey, reading. It's a live install. So regardless of what language is selected, the installed system gets whatever is in the live image. glibc-langpacks-all should be enough to make the locale data available. I'm not sure why glib-langpack-en was also installed. My suspicion is something in the dependency logic in the glibc package, as evaluated at the time the liveimg was created, so I'll try taking a look at that. As far as installing the langpack-xx packages, that's not really possible at install time from a live source. Maybe if we go back to writing langpacks.conf then dnf can figure it out afterwards. --- Additional comment from Mike FABIAN on 2016-03-18 13:31:19 EDT --- (In reply to David Shea from comment #2) > Oh, hey, reading. It's a live install. So regardless of what language is > selected, the installed system gets whatever is in the live image. Ah, OK, good! So I should also test what happens when I use the netinstall instead. > glibc-langpacks-all should be enough to make the locale data available. I'm > not sure why glib-langpack-en was also installed. My suspicion is something > in the dependency logic in the glibc package, as evaluated at the time the > liveimg was created, so I'll try taking a look at that. As far as installing > the langpack-xx packages, that's not really possible at install time from a > live source. Maybe if we go back to writing langpacks.conf then dnf can > figure it out afterwards. I think it was installed because langpacks-en was installed. Installing langpacks-en pulls in glibc-langpack-en. But I have no idea why langpacks-en was installed because the installation was in Japanese. --- Additional comment from Mike FABIAN on 2016-03-18 13:36 EDT --- --- Additional comment from Mike FABIAN on 2016-03-18 13:39:29 EDT --- (In reply to Mike FABIAN from comment #3) > (In reply to David Shea from comment #2) > > Oh, hey, reading. It's a live install. So regardless of what language is > > selected, the installed system gets whatever is in the live image. [...] > I think it was installed because langpacks-en was installed. > > Installing langpacks-en pulls in glibc-langpack-en. > > But I have no idea why langpacks-en was installed because the installation > was in Japanese. As David explained above, this is because langpacks-en was already there in the live image and the installed system gets everything which was in the live image. So if langpacks-en is on purpose in the live image, there is actually no bug here, in this case this bug can be closed. --- Additional comment from David Shea on 2016-03-18 14:46:51 EDT --- I'm moving this to dnf, since currently there is not a way to add langpacks to a liveinst installed system without explicitly installing them. Even if anaconda were to go back to writing the language data to langpacks.conf, it would not have any effect, probably due to dnf's insistence that plugins not modify the package transaction. Currently liveinst users are presented with options that appear to configure language support, but there is no way for that language support to take effect. --- Additional comment from Honza Silhan on 2016-04-01 06:57:14 EDT --- --- Additional comment from Honza Silhan on 2016-04-01 08:09:03 EDT --- I've talked to Vratislav Podzimek and it seems like during Anaconda installation from live image they just copy the files - no DNF installation happens. Possible solutions are: 1) have inside livewimage langpacks-<lang> metapackages + all the relevant langpacks to the packages. Install them all at first, then remove not selected. i.e. dnfbase.remove("langpacks-<lang>") for each not selected lang. 2) let the user choose langpack only when he is connected to the internet and then after the copying the rpms run: dnfbase.install("langpacks-<lang>") for each selected lang 3) set oneshot systemd task After=network-online.target on the first boot which will call "dnf reinstall langpacks-<lang>" for each lang selected. (that would pull in all langpacks for each installed package) Proper solution would be probably 1) or 2) so the user boots into his selected language. David, what do you think? Probably with yum the langpacks were added into the first transaction of yum run based on the langpack conf (not during the installation). --- Additional comment from Neal Gompa on 2016-04-02 17:15:46 EDT --- @Jan: I would suggest that probably option 1 is the best way to go in terms of reliability, as it doesn't require internet access to work all the time. I believe the live images are already sized up for holding all the langpacks anyway, so simply doing this would restore previous behavior and add an optimization in the form of a post-install cleanup of unnecessary language packs. --- Additional comment from Parag Nemade on 2016-04-04 00:55:42 EDT --- Currently we have 80 langpacks-* subpackages which comes around 644 kB of total size. --- Additional comment from Mike FABIAN on 2016-04-04 02:16:59 EDT --- (In reply to Parag Nemade from comment #10) > Currently we have 80 langpacks-* subpackages which comes around 644 kB of > total size. It must be more than 644 kB when considering the packages supplementing the langpacks-<lang> meta packages. One single glibc-langpack-<lang> is already more than 644 kB. --- Additional comment from Parag Nemade on 2016-04-14 12:25:17 EDT --- Any progress here? or langpacks will not be working again in F24? We are near to F24 Beta Freeze now. I wish dnf could have implemented hooks instead long before. --- Additional comment from David Shea on 2016-04-14 13:05:06 EDT --- (In reply to Jan Silhan from comment #8) > 1) have inside livewimage langpacks-<lang> metapackages + all the relevant > langpacks to the packages. Install them all at first, then remove not > selected. i.e. dnfbase.remove("langpacks-<lang>") for each not selected lang. > 2) let the user choose langpack only when he is connected to the internet > and then after the copying the rpms run: dnfbase.install("langpacks-<lang>") > for each selected lang We are absolutely not going to do some kind of hybrid payload type for live + langpacks. If this cannot be solved in the live payload itself, it will need to be solved post-install, somehow. --- Additional comment from Parag Nemade on 2016-04-27 12:21:56 EDT --- Jan, Any updates here please? --- Additional comment from Pravin Satpute on 2016-04-27 14:37:32 EDT --- This is going to impact badly for all non-english users, specifically when our change Glibc locale sub packaging is in place now. We must fix this before final release. --- Additional comment from Fedora Admin XMLRPC Client on 2016-07-08 05:31:49 EDT --- This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component. --- Additional comment from Igor Gnatenko on 2016-07-22 05:09:29 EDT --- --- Additional comment from Igor Gnatenko on 2016-07-22 05:10:43 EDT --- Reproducer: https://bugzilla.redhat.com/show_bug.cgi?id=1352350#c11 --- Additional comment from Kevin Fenzi on 2016-09-04 23:54:32 EDT --- We are now pushing updates on a fedora-24 instance so they have weak deps. Bases composes always have, so I am not sure how that helps things, but there it is. --- Additional comment from Thorsten Leemhuis on 2016-10-20 13:51:09 EDT --- What's the status of this bug? I installed Fedora Workstation 25 Beta earlier this week with de_DE.UTF-8 and langpacks-de.noarch wasn't installed automatically. So I guess this is still valid and got forgotten? --- Additional comment from Cheng-Chia Tseng on 2016-11-22 11:00:20 EST --- I did a fresh install of Fedora 25 today. The result is that zh_TW (Chinese (Taiwan), which is my locale) langpack of libreoffice is still not installed along with the installation process. --- Additional comment from JakobJakobson on 2017-01-22 12:46:49 EST --- Description of problem: The bug still applies as no German language localisation was installed along the installation of the system. Version-Release number of selected component (if applicable): Fedora 25 How reproducible: Very. Steps to Reproduce: 1. Install a Fedora 25 in GNOME boxes with selecting the German language and German keyboard layout. 2. Expect German localization. Actual results: No German localization is installed. rpm -qa | grep langpack gives: glibc-all-langpacks-2.24-3.fc25.x86_64 libreoffice-langpack-en-5.2.3.3-4.fc25.x86_64 langpacks-en-1.0-8.fc25.noarch glibc-langpack-en-2.24-3.fc25.x86_64 Expected results: German localization is installed.
*** This bug has been marked as a duplicate of bug 1319073 ***