Bug 1170730 - system config language doesn't work with Provides: only real package names
Summary: system config language doesn't work with Provides: only real package names
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: system-config-language
Version: 22
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: ---
Assignee: Parag Nemade
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 1119026 (view as bug list)
Depends On:
Blocks: plasma5
TreeView+ depends on / blocked
 
Reported: 2014-12-04 17:34 UTC by Germano Massullo
Modified: 2015-08-18 05:19 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-08-18 05:19:11 UTC


Attachments (Terms of Use)
1 (372.28 KB, image/png)
2014-12-04 17:34 UTC, Germano Massullo
no flags Details
2 (347.05 KB, image/png)
2014-12-04 17:34 UTC, Germano Massullo
no flags Details
3 (319.55 KB, image/png)
2014-12-04 17:35 UTC, Germano Massullo
no flags Details
This modified spec should rename package (58.69 KB, patch)
2015-01-15 09:19 UTC, Parag Nemade
no flags Details | Diff

Description Germano Massullo 2014-12-04 17:34:26 UTC
Created attachment 964775 [details]
1

Description of problem:
I have reproduced the following problem with many languages but I will write an example about Italian.
Installing system-config-language and kde-l10n packages on a F21 system, does not let the user to proper install the KDE langpack.
For example, in first screenshot, s-c-l wants to install kde-l10n-it package. The real name of the package is kde-l10n-Italian.
If you enter a console command like
# dnf info kde-l10n-it
dnf will return kde-l10n-Italian.noarch

so it seems that s-c-l does not do this kind of package name translation.

See the difference between selected packages in screenshot number 1 and 2, 3.


Version-Release number of selected component (if applicable):
system-config-language-2.3.0-2.fc21.noarch

Comment 1 Germano Massullo 2014-12-04 17:34:58 UTC
Created attachment 964776 [details]
2

Comment 2 Germano Massullo 2014-12-04 17:35:16 UTC
Created attachment 964777 [details]
3

Comment 3 Kevin Kofler 2014-12-04 18:26:26 UTC
So the problem is that it's passing a list of package names and/or virtual Provides to a PackageKit interface that accepts only package names.

Comment 4 Parag Nemade 2014-12-05 06:42:18 UTC
Hi Germano,

The system-config-language still uses yum and "yum install kde-l10n-it" works fine. Note, langpacks plugin needs translation packages real name in the format <pkgname>-<locale_code>. The kde-l10n package is not following this guideline.

The code in system-config-language to get package list is now similar to yum-langpacks code. The yum-langpacks just reads conditional from comps like in this case "kde-l10n-%s", so ideally package should have got named like kde-l10n-it. Langpacks plugin works on locale code but yes I have added many tweaks to fix such inconsistencies.

The proposal I gave to FPC is at https://fedoraproject.org/wiki/PackagingDrafts/LangPack and approved by them is at https://fedoraproject.org/wiki/PackagingDrafts/LangPack2

NOTE: This is still not added to Naming Guidelines by FPC. I will ping them later.

It took me some time to find when virtual provides were added in kde-l10n package but here is that http://pkgs.fedoraproject.org/cgit/kde-i18n.git/commit/?id=b7c5a12cc0c4eb907253bb44272089022e2f06cb commit. They are first added in kde-i18n package which then renamed to kde-l10n for KDE 4.x series.

There is one more reference bug https://bugzilla.redhat.com/show_bug.cgi?id=233223#c4

As said earlier, there are such many inconsistencies in fedora langpack packages and I have been asked again and again to add special parsing for such problems instead those package owners to rename their packages. Thankfully some added virtual provides and helped yum-langpacks to work fine.

So, the question is how selection of kde-l10n-it instead kde-l10n-Italian is affecting you?

Comment 5 Germano Massullo 2014-12-05 07:50:19 UTC
(In reply to Parag from comment #4)
> So, the question is how selection of kde-l10n-it instead kde-l10n-Italian is
> affecting you?

As shown in 2 and 3 screenshots, s-c-l does not install kde-l10n-it nor kde-l10n-Italian, even if in screenshot 1 package kde-l10n-it has been selected.
yum/dnf instead correctly select kde-l10n-Italian if you ask for kde-l10n-it

(In reply to Parag from comment #4)
> The system-config-language still uses yum and "yum install kde-l10n-it"
> works fine. Note, langpacks plugin needs translation packages real name in
> the format <pkgname>-<locale_code>. The kde-l10n package is not following
> this guideline.
I think you should report that to the Fedora Engineering Steering Committee to finally solve this conflict.

Comment 6 Parag Nemade 2014-12-05 10:23:29 UTC
Thanks and sorry I should have checked this in KDE before above comment. I was knowing something came up while moving system-config-language to use packagekit but forgot that. I remember now that packagekit do not resolve virtual provides.

Let me check what I can do to fix this. I will comment when I get some solution.

Comment 7 Kevin Kofler 2014-12-05 15:31:42 UTC
kde-l10n already has the virtual Provides. The problem is that system-config-language does not resolve them (but expects the PackageKit interface to resolve them, which it doesn't).

Now I have been suggesting we rename the packages to fit the standard convention, which is also how upstream names the tarballs, for a while. It might be the best solution after all.

Comment 8 Piotr Drąg 2014-12-13 09:00:15 UTC
*** Bug 1119026 has been marked as a duplicate of this bug. ***

Comment 9 Parag Nemade 2014-12-13 09:45:21 UTC
Note here, if someone from KDE SIG can update that if they still have no plans to rename packages then only I will check system-config-language code and will see if I can fix it there by adding special parsing. 

But I also want to add here that we have now https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Addon_Packages_.28langpacks.29 in effect.

Comment 10 Parag Nemade 2015-01-14 15:01:44 UTC
Any updates here? We are now started with F22 development. We can rename packages now.

Let me move this to kde-l10n.

Comment 11 Rex Dieter 2015-01-14 15:05:58 UTC
I can certainly rename the kde-l10n packages if that is needed (it's that until now, I've been consistently told that was not required, and that the virtual Provides: were enough).

Comment 12 Parag Nemade 2015-01-14 15:40:04 UTC
Happy to read above comment :)

Let me do some analysis if there will be any inconsistency in usage of any kde-l10n-<localecodes> with langpacks plugin. I will comment here by tomorrow.

Comment 13 Parag Nemade 2015-01-15 09:00:44 UTC
Looks like only 2 locales

1) Venda langauage, langcode should be used "ve" and not "ven"
we have /usr/share/locale/ve locale file.

2) I think its good to use the same virtual provides ca-valencian as a langcode for Catalan-Valencian langpack. 

rest all virtual provides names looks fine to become actual package names.

Comment 14 Parag Nemade 2015-01-15 09:19:43 UTC
Created attachment 980378 [details]
This modified spec should rename package

Tested this spec with copr build https://copr.fedoraproject.org/coprs/pnemade/misc/build/67691/

seems dnf update to this copr repo worked fine.

Comment 15 Rex Dieter 2015-01-15 15:40:23 UTC
fyi, you included some other unrelated changes as well

but I think I can work with that, rather than doing it from scratch.

Comment 17 Parag Nemade 2015-01-15 16:00:26 UTC
Sorry I forgot to mention I removed some old obsoletes as we added new obsoletes and Group tag from all subpackages.

Thank you for committing the required changes for this bug.

Comment 18 Rex Dieter 2015-03-24 15:40:40 UTC
We worked around the system-config-language deficiency in kde4's kde-l10n translations, but doing the same with qt5/kf5 will be not practical.

What kde-sig would like to see from system-config-language:

* fix to recognize <pkg>-<locale> virtual Provides too and not just real package names (like yum-langpacks did)

or possible hack/workaround in the meantime:
* upon any request to install langpacks for new locale, check if qt5-qtbase is installed and if so, pull qt5-qttranslations into the transaction.

Comment 19 Parag Nemade 2015-03-25 08:12:37 UTC
Can someone please provide more details here? Sorry I do not follow or use KDE much, only for testing some features/bug. I can tweak the langpacks code if needed.

Comment 20 Rex Dieter 2015-03-25 12:53:06 UTC
Sure, in the kde-l10n case, you asked us to rename the packages to
kde-l10n-<locale>  (ie, kde-l10n-de)
from
kde-l10n-<fullname> (ie, kde-l10n-German)

because system-config-language wasn't able to handle that
kde-l10n-German included:
Provides: kde-l10n-de
properly

Well, making the kde-l10n change was relatively easy, but doing that for qt5-qttranslations will be *much* harder and invasive, so what I'm asking is to either

1.  fix system-config-language to work properly with packages that simply:
Provides: <foo>-locale
too, instead of insisting a real package named <foo>-locale exists

or

2.  always install qt5-qttranslations in the special case that qt5-qtbase is installed (and an additional language pack is being requested).


Does that help?

Comment 21 Kevin Kofler 2015-03-25 12:56:33 UTC
The thing is that there is one qt5-qttranslations package with all translations, and we are thinking of just adding Provides: qt5-qtbase-$lang for every language it contains.

Comment 22 Parag Nemade 2015-03-26 09:42:19 UTC
I looked into current kde-l10n.spec and qt5-qttranslations.spec files. In current scenario, if the case is that when kde-l10n-de gets installed qt5-qttranslations should also be installed then adding "Recommends: qt5-qttranslations" to every kde-l10n-* subpackage works fine.

If there are plans to add subpackaging per locale based then can you confirm you people want to do that as like qt5-qttranslations-de?

I am still not clear what is getting changed. Please someone give more dependency details. Also, if there are new language packs then can we add langpacks comps entry for that?

Comment 23 Rex Dieter 2015-03-26 13:37:08 UTC
Recommends won't work for yum

As far as qt5-qttranslations, yes, I was planning on adding Provides:
qt5-qttranslations-de
etc...
as appropriate (not done yet)

Re: comps
comps doesn't include langpacks anymore (not for awhile), so that's not a viable option.

Comment 24 Rex Dieter 2015-03-26 13:38:55 UTC
Re: comps
I take it back, there are language support groups, but they're generally only for fonts and input methods these days.

Comment 26 Fedora Update System 2015-03-26 19:26:12 UTC
qt5-qttranslations-5.4.1-2.fc22 has been submitted as an update for Fedora 22.
https://admin.fedoraproject.org/updates/qt5-qttranslations-5.4.1-2.fc22

Comment 27 Parag Nemade 2015-03-28 04:45:23 UTC
(In reply to Rex Dieter from comment #24)
> Re: comps
> I take it back, there are language support groups, but they're generally
> only for fonts and input methods these days.

I meant to say if there is new base package is introduced that provides language packages then if base package is installed on the system langpacks plugin can pull its translations. After looking into your change. I see that you should add to comps file as

diff --git a/comps-f22.xml.in b/comps-f22.xml.in
index 64a253c..651a7ba 100644
--- a/comps-f22.xml.in
+++ b/comps-f22.xml.in
@@ -7567,6 +7567,7 @@
     <match install="moodle-%s" name="moodle"/>
     <match install="mythes-%s" name="mythes"/>
     <match install="nqc-doc-%s" name="nqc-doc"/>
+    <match install="qt5-qtbase-%s" name="qt5-qtbase"/>
     <match install="sagemath-doc-%s" name="sagemath-doc"/>
     <match install="stardict-dic-%s" name="stardict"/>
     <match install="tagainijisho-dic-%s" name="tagainijisho-common"/>

Above is the patch for comps-f22.xml.in file for its current checkout.

This will then ensure that if and only if qt5-qtbase is installed on the system then langpacks plugin will pull the qt5-qtbase-%s package.

At least I will need this first to work on langpacks plugin code modification.

Thanks.

Comment 28 Parag Nemade 2015-03-29 04:27:27 UTC
I really need above to test langpacks plugin so I gone ahead and make the changes in rawhide comps only for now.

Comment 29 Parag Nemade 2015-03-30 04:36:20 UTC
Looks like changes to F23 comps are working and my local modified copy of dnf-langpacks can now pick qt-qttranslations. Therefore, making the changes to F22 comps also.

Note, I am doing some testing with upcoming dnf-langpacks release now.

Comment 30 Rex Dieter 2015-03-30 13:14:58 UTC
OK, so the langpack pkg doesn't *have* use the same basename?  Would adding Provides like:

qt5-qttranslations-$locale

combined with comps change:

<match install="qt5-qttranslations-%s" name="qt5-qtbase"/>

work too?

Comment 31 Parag Nemade 2015-03-30 14:05:28 UTC
Yes that should work fine.

Comment 32 Parag Nemade 2015-03-30 14:21:24 UTC
Also, dnf-langpacks-0.9.0-2 is submitted as an update for F21+ releases which should show corresponding qt5-qttranslations package if qt5-qtbase is installed for "dnf langinfo <locale> and dnf langinstall <locale>" commands.

About this bug, I will look into system-config-language code modification. As we know system-config-language uses yum currently and the requested fix for this bug is only available in dnf-langpacks. I am planning to drop yum support in F22+ system-config-language and have it only working with dnf but need to check if other spins still want to use yum.

Comment 33 Germano Massullo 2015-03-30 15:22:39 UTC
Hi Parag, on F22 TC5 I have found similar problems of F20: system partially translated in Italian, the s-c-l cursor is setted on Italian language but kde-l10n-it package is not installed. To install it I must switch in s-c-l to another language and then switch again to Italian

Comment 34 Parag Nemade 2015-03-31 05:47:21 UTC
I suppose you have installed your system in Italian language. Is it that you installed from KDE Live iso? If so then I just did its testing and found again anaconda-langpacks yum plugin not working. But this time I see that anaconda stopped using yumpayload.py and moved to dnfpayload.py where the anacoda-langpacks integration is not yet coded.

I have already that request pending to anaconda developers. I will check on this.

Comment 35 Kevin Kofler 2015-03-31 12:42:02 UTC
The fact that kde-l10n-* is not on the KDE image is expected, it has always been like that, for space reasons. What should happen is that setting the language to Italian in s-c-l drags it in. Now the problem is that if you already select Italian in liveinst, it happily sets the system language to Italian, assuming the langpacks are already there, which is not necessarily the case. Then s-c-l does not realize it needs to install anything unless you change to another language and back.

So the problem is in liveinst or s-c-l, not in the payload code.

Comment 36 Germano Massullo 2015-04-13 13:57:27 UTC
(In reply to Parag from comment #34)
> I suppose you have installed your system in Italian language.
Yes

> I have already that request pending to anaconda developers. I will check on this.
Any news?

(In reply to Kevin Kofler from comment #35)
> The fact that kde-l10n-* is not on the KDE image is expected, it has always
> been like that, for space reasons.
The Fedora Spins ISOs are no longer able to be burned to Compact Discs (>700MB), so I think there are no more space reasons....

Comment 37 Rex Dieter 2015-04-13 14:06:47 UTC
Space is always (and still is) an issue.

Comment 38 Kevin Kofler 2015-04-13 18:21:26 UTC
In particular, including all kde-l10n-* would probably blow even our current 1.4 GB size target.

Comment 39 Parag Nemade 2015-04-14 15:25:45 UTC
Hi Germano,
   I am not seeing langpacks plugin working soon while doing an anaconda installation. Anaconda people are saying https://bugzilla.redhat.com/show_bug.cgi?id=1178969#c6
   So, for now one need to manually install langpacks using its command langinstall or system-config-language package.
   Btw I have enabled the "Ok" button in system-config-language UI. You should be able to install now any remaining langpack packages for your default language. This change is available in system-config-language-2.4.2 builds in F22+ releases.

Comment 40 Fedora Update System 2015-04-21 18:53:49 UTC
qt5-qttranslations-5.4.1-2.fc22 has been pushed to the Fedora 22 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 41 Parag Nemade 2015-08-18 05:19:11 UTC
I suppose this bug is fixed already in F22. Please open new bug for any other issues.


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