On Thu, Jul 5, 2018, 20:42 Tomasz Kłoczko <kloczko.tomasz@gmail.com> wrote:
On Thu, 5 Jul 2018 at 16:08, Zbigniew Jędrzejewski-Szmek
<zbyszek@in.waw.pl> wrote:
[..]
> Anyway, the langpacks split was made with full awareness of %_install_langs,
> see https://fedoraproject.org/wiki/Changes/Glibc_locale_subpackaging.

Yep and simple this makes glibcs.spec one of the most complicated
Fedora specs files by implementing generate set of sub packages to
install lang dependent resources. If glibc and few other packages will
be only using %lang() and everything aroud will be adding proper
%_install_langs settings it will be not necessary to create next
almost 200 glibc sub packages.
Even separation glibc-minimal-langpack files is pointless because
those files must be installed always to not have constantly annoying
warning messages about missing locale "C" files.

[..]
> > Result is obvious: number of *langpack* packages is growing.
> I don't think this is a big problem. The number of languages that can
> be supported can't go much higher (in principle there's maybe ~2000 languages
> alive nowadays, but most of them are dying quickly, and are unlikely to ever
> get glibc locale support). The 192 langpacks we have now is nothing compared
> to the texlive package list.

Just please correct me if I'm wrong. Does it mean that someone already
started thinking about generate another 2k TeX packages? =8-O
If it is true I'll put my private money to fund for this person
special IgNoble price :)

Fedora has those only glibc sub packages  because nothing OOTB in
installer adds /etc/rpm/macros file with single line of text forefeet
start install first package.
Many packages have already marked man pages and gettext .mo files
which have proper %lang() metadata.
How you can compare probably single python code modification in
kickstart code to number of man/hour resources spend by all Fedora
packagers which are maintaining *langpack* sub packages scheme and
man/hour resources already spent by Fedora end users choosing those
langpacks?

Yes .. this is level; of the "elegance and simplicity" which many
Fedora packages already are trying hardly avoid by any cost.

Again .. just please try sometimes to think a bit broader.
If you will repeat enough times "I don't think this is a big problem"
by a mass of those even smallest issues at least one big problem
sooner or later will start kicking back. You already must know that
this effect is well know in engendering and its name is "dead by
thousands cuts".

Someone implementing langpacks in glibc have been trying to not
install some resources at the same time lost all other .mo and %lang)
depended files installed in the system.
This like trying to move around few buckets of sand sitting in the
middle of the desert.
How big proportion is between those disk space which is possible to
"save" by using proper set  of *langpack* packages you can check on
you own system by add /etc/rpm/macros with line like:

%_install_langs en,pl

(or any other set of the languages) is possible to check by run below oneliner:

# rpm --rebuilddb; dnf cean all; df -k /; rpm -qal|grep
LC_MESSAGES|xargs rpm -qf 2>&1|sort|uniq| xargs dnf -yq reinstall; rpm
--rebuilddb; df -k /

Look here, you have to reinstall RPM with new settings which means you have to download full RPM. Main advantage of langpack subpackages us that you can install them granularly with downloading just translations.

In future I am hoping that those will be generated automatically.

and compare reduction used disk space to summary size of all Fedora
glibc-langpack* packages.

kloczek
--
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-leave@lists.fedoraproject.org
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@lists.fedoraproject.org/message/UDFAFJOR23NC7KCOFSWGWYOYFO33UXV6/
--

-Igor Gnatenko