So what do you propose? Here we have thread about pulling all Lang's instead of just minimal set. You describe how Solaris works. If you feel that there is architecture change is needed, then please start separate topic.
-- On Fri, Jul 6, 2018, 18:32 Tomasz Kłoczko <kloczko.tomasz@xxxxxxxxx> wrote:
On Fri, 6 Jul 2018 at 15:02, Igor Gnatenko
<ignatenkobrain@xxxxxxxxxxxxxxxxx> wrote:
[..]
>> # 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.
As long as all packages is possible to download only in form of whole
packages archives above it is only way to apply things like changing
some installed packages lang or other setting. In other words it is
something which is embedded into rpm philosophy/design.
For example IPS is using "facets" concept so to change something like
above you need one command:
# pkg change-facet locale.*=false locale.en=true locale.pl=true
Uninstalling all documentations? No problem ..
# pkg change-facet doc.*=false
Install only man pages?
# pkg change-facet doc.man=true.
(yeah ,, there are more than one type of documentation files to install or not)
You can combine as well more than one facet like locale.en=true and
doc.man=true to install only man pages in exact language(s).
Transform whole system to devel env is as well incredibly easy:
# pkg change-facet devel=true
No devel sub packages !!! :)
And after finishing compile some binaries ..
# pkg change-facet devel=false
Those operations may look simple during those changes is working whole
dependency checking machinery so if install or uninstall some sub
types of package files may break some dependencies (which are
connection resources knots not on whole packages level but each files)
such operation will fail with error message.
All is b*dy easy to do because all packages exist only in repositories
as separated files. Some files like ELF binaries may exist even in the
same repository as object owned by multiple versions of the package or
in architecture dependent types.
This allows for example on doing upgrade some A package from V.1 to
V.2 download only those files which has been changed between versions.
Without such design changes on packages representation side using
current rpm trying to implement something like Modularity will be
nothing more than Sisyphus work.
IPS already uses facets and variants more than decade ..
https://docs.oracle.com/cd/E23824_01/html/E21802/glmke.html
If you are interested try to read about other IPS concepts like
consolidation. This little thing solves all possible problems of have
some issues because something has been build not in environment of
exact versions of other packages.
But again .. as nothing in kickstart adds during initial installation
in /etc/rpm/macros lines about supported languages or settings to
install or not documentation only way to maintain two possible
optionally to install types of files using rpm is creating more and
more packages.
Wen you will try to install Solaris (you can use even free
OpenIndiana) just check how many types only facets is possible to
change in something like typical(tm) installation.
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/message/PKDHMCKI33YZMVU2GI5LOPV34WDGSXHM/
-Igor Gnatenko
_______________________________________________ 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/message/3YB55YBMOOHYIXV5IPEZFZEO5BGVCE35/
