On Wed, 9 Jan 2019 at 21:07, Ben Cotton <bcotton@xxxxxxxxxx> wrote:
https://fedoraproject.org/wiki/Changes/Replace_Comps_Language_Group_With_Langpacks
== Summary ==
Language support groups in Comps file will get replaced by langpacks
package. With this Change we want meta-packages like langpacks-ja to
also install required fonts and input-methods for the given language.
== Owner ==
* Name: [[User:petersen| Jens Petersen]]
* Email: petersen at fedoraproject dot org
* Name: [[User:pnemade| Parag Nemade]]
* Email: pnemade at fedoraproject dot org
== Detailed Description ==
This change will remove the need of having the language specific comps
groups in Fedora.
We already have ''langpacks-*'' packages in Fedora since F24.
Currently they are installing language packages for translations,
dictionaries etc. but not fonts or input-methods. With this Change we
will try to install fonts and input-methods as well.
E.g. if you net-install Fedora in Japanese language then installation
of any base package like libreoffice-core or man-pages are installing
automatically libreoffice-langpack-ja or man-pages-ja but langpacks-ja
is not installing any Japanese font or input-method.
But now with using RPM tags or weak dependencies like Supplements, we
can get font as well as input-method packages installed as well on the
system.
There is no need of language comps groups to exist, they will be
replaced by langpacks.
This Change is originally submitted at https://pagure.io/i18n/issue/97
== Benefit to Fedora ==
Users can install complete language support now using langpacks only.
This will also help to remove the language support groups from the
comps file.
It is really shame that instead just setting up /etc/rpm/macros::%_install_langs on distro install time people are discussing how to waste time to create even more langpacks.
The same is with separating doc subpackages which can be done by /etc/rpm/macros::%_excludedocs yes or use --excludedocs on single package install/upgrade.
If those functionalities are not used why not to remove code handling that from rpm and remove using %doc tags?
Instead implementing handle more class files like it has IPS with facets [1] seems like most of the Fedora packagers want to waste to the end of the word more and more time on create even more subpckages classes to fulfil demands of installed resources customisation.
In time when most of the people using computers are trying to automate as much as possible Fedora for some reasons chose to go in completely opposite direction.
Again .. shame, really shame.
Funny (and scary) is that anaconda provides function to choose exact languages support when system is installed but nothing is added to /etc/rpm/macros to really make this choice real.
%find_lang macro takes care of tagging some files using %lang() macros but nothing in the rest of the Fedora is going to use those tags.
Maybe it would be better to abandon use %find_lang?
Why no one is taking care to convert more and more man pages in source trees (like I've done it more than decade ago in shadow-utils) to embed proper maintenance platform to keep up-to-date exact package man pages to other languages and still most of those man pages are desync state (in refer to original eng versions) and still maintaining man-pages-<lang> packages which usually installs many man pages which are for some packages not installed in system image?
IMO all man-pages-<lang> packages should disappear from distribution.
%find_lang used --with-man option takes care of collecting all language specific man pages as well, and more than 100 Fedora package are using this option .. but again nothing during fresh Fedora install is using those tags.
kloczek
--
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
