Bug 1182110
| Summary: | [pt-BR] [pt-PT] [zh-Hans] [zh-Hant] rename these langpack packages | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Parag Nemade <pnemade> |
| Component: | libreoffice | Assignee: | Caolan McNamara <caolanm> |
| Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 22 | CC: | caolanm, dtardon, erack, jgrulich, mstahl, sbergman |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2015-08-13 09:22:27 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Parag Nemade
2015-01-14 13:05:53 UTC
This package naming problem exists in Fedora since long time, maybe not reported before but now we have naming guidelines which we can use and follow. For a quiet life I can swap the name vs the provides. If I had enough resources I'd tackle things the other way around and change all our stacks to be langtag aware. Some other year maybe :-) (In reply to Parag from comment #0) > Note the virtual provides will not work as yum-langpacks can read actual rpm > package names only and there is no yum API that can help to find virtual > package names. Lacking yum API is irrelevant as an argument, as Fedora is switching to dnf. The question is: will a future dnf langpacks plugin be able to do this? If not, it should be proposed as an enhancement to dnf. Changing package names to fit a specific pattern is just a needless bureaucracy. yum-langpacks and dnf-langpacks will be same. We already have naming guidelines added for this in Fedora and it will be good if libreoffice also follows these guidelines. I really not sure what to reply to existing bug that needs this change and maybe in future also we will get bugs reported that langpacks plugin failed to install libreoffice translation packages. Other packages in Fedora already follows pt_BR in their package names. (In reply to Parag from comment #4) > yum-langpacks and dnf-langpacks will be same. That does not answer my question. IIRC one of the reasons to start dnf was to have better API for plugins. So is there a _technical_ reason why this is not possible? > We already have naming > guidelines added for this in Fedora and it will be good if libreoffice also > follows these guidelines. The reasoning, which led to acceptance of the naming guideline, was exactly the same as here: yum-langpacks is broken. If dnf-langpacks could handle virtual provides, it would not be necessary and could be removed again. > > I really not sure what to reply to existing bug that needs this change and > maybe in future also we will get bugs reported that langpacks plugin failed > to install libreoffice translation packages. And they would be bugs in dnf-langpacks. > Other packages in Fedora > already follows pt_BR in their package names. That does not imply that all packages have to do it. (In reply to David Tardon from comment #5) > (In reply to Parag from comment #4) > > yum-langpacks and dnf-langpacks will be same. > > That does not answer my question. IIRC one of the reasons to start dnf was > to have better API for plugins. So is there a _technical_ reason why this is > not possible? > > > We already have naming > > guidelines added for this in Fedora and it will be good if libreoffice also > > follows these guidelines. > > The reasoning, which led to acceptance of the naming guideline, was exactly > the same as here: yum-langpacks is broken. If dnf-langpacks could handle > virtual provides, it would not be necessary and could be removed again. I don't accept that because yum do not provide to find virtually provided package names then it is a bug. Langpacks plugin uses simple logic. Read the available packages in the repository. Read the given input locale code say pt_BR. Then search packages that ends with pt_BR and use that package set as supported langpack packages for pt_BR language. Now consider if dnf people will modify filter api which will start giving virtually provided package names. Langpacks plugin will find both the names libreoffice-langpack-pt-BR and libreoffice-langpack-pt_BR. Now when enduser uses command "dnf langinfo pt_BR" he will see supported package name as "libreoffice-langpack-pt_BR" which is a lie to user as there is no such real package name. I really think this is not good to confuse end-users. I just want to keep simple langpacks plugin. > > > > > I really not sure what to reply to existing bug that needs this change and > > maybe in future also we will get bugs reported that langpacks plugin failed > > to install libreoffice translation packages. > > And they would be bugs in dnf-langpacks. I don't understand why dnf-langpacks need to face for packagers mistakes for not following naming guidelines? If that is the case I will end up writing such cases and that will be un-necessary code for this simple langpacks plugin. > > > Other packages in Fedora > > already follows pt_BR in their package names. > > That does not imply that all packages have to do it. The langpacks packaging naming guidelines is not for just langpacks plugin but to have some uniqueness in package names and identify easily that those are only translations providing packages. This bug appears to have been reported against 'rawhide' during the Fedora 22 development cycle. Changing version to '22'. More information and reason for this action is here: https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora22 It's sad I have not got any help here for langpacks plugin for yum and dnf from libreoffice maintainers. |