On Thu, Apr 18, 2024 at 3:18 PM Jan Engelhardt wrote:

On Thursday 2024-04-18 14:08, Stefan Seyfried via openSUSE Factory wrote:

...

I recently installed a new laptop with Tumbleweed instead of my old habit of just moving over the installed disk. Now I'm facing some issues that were not present before in my old installation.

One of these issues is that something wants to pull in addiditonal -lang packages that I do not want:

mixi:~ # zypper -v dup --no-recommends [...] The following 8 NEW packages are going to be installed: cpupower-lang 6.8.6-7.9 file-roller-lang 44.1-1.1 gcr-lang 4.3.0-1.1 gnome-online-accounts-lang 3.50.1-1.1 gtk3-lang 3.24.41-2.1 icewm-lang 3.4.5-3.1 pipewire-lang 1.0.4-3.1 xz-lang 5.6.1.revertto5.4-3.1

As you can see, I already added "--no-recommends" as every experienced user obviously always does, but the *-lang are still added.

If you used --no-recommends, then the proposed packages surely are due to a strong require, which means after installation you can `rpm -e xz-lang` and see who's hard-requiring it.

That, or `zypper lloc` is now independent of --no-recommends :-/

The latter. andrei@tumbleweed:~> zypper locales Code | Language | Requested -----+----------+---------- de | German | Requested en | English | Fallback andrei@tumbleweed:~> sudo zypper in cpupower Loading repository data... Reading installed packages... Resolving package dependencies... The following 3 NEW packages are going to be installed: cpupower cpupower-lang libcpupower1 3 new packages to install. Overall download size: 205.4 KiB. Already cached: 0 B. After the operation, additional 488.9 KiB will be used. Backend: classic_rpmtrans Continue? [y/n/v/...? shows all options] (y): n andrei@tumbleweed:~> zypper info --supplements cpupower-lang Repository 'openSUSE-Tumbleweed-Non-Oss' is out-of-date. You can run 'zypper refresh' as root to update it. Repository 'openSUSE-Tumbleweed-Oss' is out-of-date. You can run 'zypper refresh' as root to update it. Repository 'openSUSE-Tumbleweed-Update' is out-of-date. You can run 'zypper refresh' as root to update it. Loading repository data... Reading installed packages... Information for package cpupower-lang: -------------------------------------- Repository : openSUSE-Tumbleweed-Oss Name : cpupower-lang Version : 6.8.6-7.9 Arch : noarch Vendor : openSUSE Installed Size : 82.5 KiB Installed : No Status : not installed Source package : cpupower-6.8.6-7.9.src Upstream URL : https://git.kernel.org/cgit/linux/kernel/git/rafael/linux-pm.git Summary : Translations for package cpupower Description : Provides translations for the "cpupower" package. Supplements : [6] (cpupower and namespace:language(cs)) (cpupower and namespace:language(de)) (cpupower and namespace:language(fr)) (cpupower and namespace:language(it)) (cpupower and namespace:language(ka)) (cpupower and namespace:language(pt)) andrei@tumbleweed:~>

* Eric Schirra [04-18-24 11:28]:

Am 18. April 2024 15:46:47 MESZ schrieb "Carlos E. R." :

...

On 2024-04-18 14:08, Stefan Seyfried via openSUSE Factory wrote:

...

Hi all,

...

...

As you can see, I already added "--no-recommends" as every experienced user obviously always does, but the *-lang are still added.

No, we don't all do that. :-)

+1

but, quite a few of us do and whether we "all" do or not is irrelivant. the problem, anomaly does exist and is of concern to those who do. I have seen the problem for years not and frequently: rpm -e --nodeps iso-codes-lang ; zypper -v rm *-lang quite frequently. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet oftc

On 18.04.2024 20:59, Togan Muftuoglu via openSUSE Factory wrote:

...

...

...

...

...

"PS" == Patrick Shanahan writes:

PS> but, quite a few of us do and whether we "all" do or not is PS> irrelivant. the problem, anomaly does exist and is of concern to those PS> who do.

PS> I have seen the problem for years not and frequently: rpm -e --nodeps PS> iso-codes-lang ; zypper -v rm *-lang

Maybe it's time to add --nodeps flag to zypper

You explicitly told zypper that you want locale support. Now you complain that zypper installs locale support and want flag to tell zypper to ignore what you configured. If you do not want locale support, do not configure zypper to install locale related packages.

Am 18.04.24 um 20:07 schrieb Andrei Borzenkov:

You explicitly told zypper that you want locale support. Now you

No, yast implicitly did that when I did install with german language setting.

complain that zypper installs locale support and want flag to tell zypper to ignore what you configured.

I want "--no-recommends" to not install "only recommended" packages. Now technically it was even correct, beause the -lang packages are "Supplements". So let's try with "--no-supplements" added: mixi:~ # zypper -v dup --no-supplements --no-recommends Verbosity: 2 The flag --no-supplements is not known.

If you do not want locale support, do not configure zypper to install locale related packages.

I'll try to remember not to install with non-en_US locale ever again :-) -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman

On Fri, 2024-04-19 at 11:17 +0300, Andrei Borzenkov wrote:

Sure, it would be nice to have more visibility into what installer does and what various settings language selection affects. As well as more documentation on what various zypper options actually do :)

Indeed, as several long-time users have confessed in this thread that that they'd never heard about the aloc/lloc/rloc commands before (neither did I). Side note - I don't see much value in openSUSE's all-or-nothing approach to language support. It's interesting to see that zypper seems to have a concept of "requesting" locales. But installing any locale other than the default means installing -lang packages with support for all languages supported by the package, while the average user will need no more than one language besides English. Are there any packages that actually provide language support split by language? (I don't see any). Is there tooling support for creating such split packages? Are there plans to introduce such support? Regards, Martin

On Fri, 2024-04-19 at 11:50 +0200, Carlos E. R. wrote:

If the languages parts are small, there is no much saving by doing separate packaging. The view in Linux seem to be better install all languages, so that all users of a single machine can choose their own different languages, all being available.

Is this "the view in Linux"? Has it been discussed in the openSUSE project?  I can see the point somewhat - minimalists will just use the "C" locale anyway, and for others the full pack may be most convenient. But not me. When I was still a Debian user, "localepurge" used to be my friend. And: zypper has this feature, so why can't some more packages use it?

Disk space is cheap :-p

Some people still have old laptops without quasi-limitless disk space. Others have better uses for their disk space than storing support file for languages they don't use. And it's not just disk space. It's also backup space, network bandwidth, and precious user time spent waiting for updates to finish. Regards Martin

On 19.04.2024 19:34, Carlos E. R. wrote:

Ideally, there should be a method to only install the language files one is interested in. Even if the package is a single one for all languages, the installation utilities could be coded to only install the wanted languages "somehow".

RPM can do it for as long as I remember and Mandrake used it 20 years ago. https://wiki.mageia.org/en/Packaging_localisation_policy

Le vendredi 19 avril 2024 à 21:20 +0300, Andrei Borzenkov a écrit :

On 19.04.2024 19:34, Carlos E. R. wrote:

...

Ideally, there should be a method to only install the language files one is interested in. Even if the package is a single one for all languages, the installation utilities could be coded to only install the wanted languages "somehow".

RPM can do it for as long as I remember and Mandrake used it 20 years ago.

https://wiki.mageia.org/en/Packaging_localisation_policy

And it was a pain to manage, when people were enabling new locales after initial install. -- Frederic CROZAT Enterprise Linux OS and Containers Architect SUSE

(slowly getting slightly offtopic ;-) Am 19.04.24 um 17:51 schrieb Martin Wilck via openSUSE Factory:

Some people still have old laptops without quasi-limitless disk space. Others have better uses for their disk space than storing support file for languages they don't use. And it's not just disk space. It's also backup space, network bandwidth, and precious user time spent waiting for updates to finish.

Then be careful what you wish for ;-) I remember when "the big texlive modularization" happened and we went from 5 to 5000 texlive packages (numbers might be slightly off). While this does not change the actual size of the update, the size of the repo metadata exploded back then. (I think the other metadata explosion was when kernel packages got every single function / module symbol included in their provides list.) So if we split out each locale in each -lang package (~1700 right now in Tumbleweed), we might end with 10000 -lang packages and that will again make the metadata explode in size. In Tumbleweed it is not as bad, but try Leap 15.5, the metadata update when refreshing repos is almost always way bigger than the actual package updates. But this might be solvable with some common sense: a -lang package which, containing all languages is only a few hundred kB is maybe not as urgent to be split up, while others like NetworkManager where the -lang package is 10 times the size of the main package and contains 64 locales might be worthwile targets. So as I said: be careful what you wish for :-) -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman

* Stefan Seyfried via openSUSE Factory [04-19-24 03:00]:

Am 18.04.24 um 20:07 schrieb Andrei Borzenkov:

...

You explicitly told zypper that you want locale support. Now you

No, yast implicitly did that when I did install with german language setting.

...

complain that zypper installs locale support and want flag to tell zypper to ignore what you configured.

I want "--no-recommends" to not install "only recommended" packages.

Now technically it was even correct, beause the -lang packages are "Supplements". So let's try with "--no-supplements" added:

mixi:~ # zypper -v dup --no-supplements --no-recommends Verbosity: 2 The flag --no-supplements is not known.

...

If you do not want locale support, do not configure zypper to install locale related packages.

I'll try to remember not to install with non-en_US locale ever again :-)

not sure that will help, I always install *only* en_US and still get *-lang packages with "--norecommends". -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet oftc

* Joe Salmeri [05-02-24 14:28]:

On 4/18/24 2:07 PM, Andrei Borzenkov wrote:

...

On 18.04.2024 20:59, Togan Muftuoglu via openSUSE Factory wrote:

...

...

...

...

> > "PS" == Patrick Shanahan writes:

     PS> but, quite a few of us do and whether we "all" do or not is      PS> irrelivant. the problem, anomaly does exist and is of concern to those      PS> who do.

     PS> I have seen the problem for years not and frequently: rpm -e --nodeps      PS> iso-codes-lang ; zypper -v rm *-lang

Maybe it's time to add --nodeps flag to zypper

You explicitly told zypper that you want locale support. Now you complain that zypper installs locale support and want flag to tell zypper to ignore what you configured.

If you do not want locale support, do not configure zypper to install locale related packages.

I have not modified the default zypper config and yet I also run into the issue of the language packages being installed.

zypper lloc

Code | Language | Requested ------+-------------------------+---------- en | English | Fallback en_US | English (United States) | Requested

grep -i locale /etc/zypp/zypp*.conf

/etc/zypp/zypp.conf:## A list of locales for which translated package descriptions should /etc/zypp/zypp.conf:## Valid values: List of locales like 'en', 'en_US'... /etc/zypp/zypp.conf:## If data for a specific locale are not available, we try to find some /etc/zypp/zypp.conf:# repo.refresh.locales = en, de

All configuration lines are just comments.

The zypper addlock '*-lang" didn't work for me because then when iso-codes-lang needs updating it fails because it is locked.

I end up manually removing all *-lang packages except for iso-codes-lang and then added locks for all the language packages that I removed.

removing iso-codes-lang causes no problem but wants to take many apps with it. rpm -e --nodeps iso-codes-lang will remove it w/o affecting other apps.

Whenever a new one gets installed I remove it and add a lock for it.

So where is the configuration that you refer to that will stop it from installing the language packages ?

-- Regards,

Joe

-- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet oftc

On 02.05.2024 21:25, Joe Salmeri wrote:

So where is the configuration that you refer to that will stop it from installing the language packages ?

zypper removelocale en_US

Am 02.05.24 um 9:33 PM schrieb Joe Salmeri:

On 5/2/24 3:26 PM, Andrei Borzenkov wrote:

...

On 02.05.2024 21:25, Joe Salmeri wrote:

...

So where is the configuration that you refer to that will stop it from installing the language packages ?

zypper removelocale en_US

Don't I want that since I'm in the United States ?

You said you didn't want any *-lang packages and in that case removing all locales should be the right thing to do. Some *-lang packages declare support for en_US, for example firewalld-lang provides locale(firewalld:en_US) via /usr/share/locale/en_US/LC_MESSAGES/firewalld.mo. I have no idea what happens if you remove firewalld-lang, and why a localization for en_US exists. Usually en_US is built in, but maybe not here, or maybe they've decided to duplicate it anyway. You can find all packages providing en_US/en locales like this: zypper search --provides 'locale(*:en_US)' zypper search --provides 'locale(*:en)' And maybe (see below): zypper search --provides 'locale(*:en_*)'

It isn't clear to me what the difference between the 2 reported by zypper lloc ?

Are you saying that 'en' and 'en_US' are really the same and that zypper is installing the languages because there is more than one code/language configured?

My understanding is that zypper automatically looks for providers of locale(X:L) for all installed packages X and all "requested" locales L. If a requested locale is not available, but the "fallback" locale is, that is selected instead. In your case, you get all locale(*:en_US) corresponding to packages that you have, plus all locale(*:en) for packages that you have that don't have a corresponding locale(*:en_US). Likely the fallback accepts any en_*, in which case you'd get the en_GB localization or whatever else might be there. That's what you want for small countries: a Swiss German (or German-speaking Swiss) would select de_CH as locale. They'd get de_CH for packages that have it, but there are probably not a lot of them. However, a Swiss German should still understand other German dialects, and so they get de_DE (German as written in Germany) as fallback that most packages should have. Same goes for all the Spanish-speaking countries, and so on. And a British user might also appreciate that their computer talks to them in British English and falls back to AE only if BE isn't available.

If so, maybe the install process needs to be updated so it doesn't do that ?

If en_US is guaranteed to always be built in, it should probably be excluded from locales. But I'm not sure if that's the case. Otherwise, packages should perhaps themselves provide locale(*:en_US) if they have localization and en_US built in. But that seems like a bit of work that someone would have to invest. ;) If nobody is willing to do that, you'll have to live with the *-lang packages or drop your en_US locale as Andrei suggested. Aaron

Am 02.05.24 um 20:25 schrieb Joe Salmeri:

I have not modified the default zypper config and yet I also run into the issue of the language packages being installed.

zypper lloc

Code  | Language                | Requested ------+-------------------------+---------- en    | English                 | Fallback en_US | English (United States) | Requested

So where is the configuration that you refer to that will stop it from installing the language packages ?

man zypper /lloc read the two following paragraphs. Even I was able to do that and remediate the issue so you should be able to do that, too ;-) -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman

Am 06.05.24 um 17:56 schrieb Joe Salmeri:

Assuming one did 'zypper rloc en_US', I wonder what Yast2 would display for the language since "en" by itself is not in the list ???

Yast doesn't seem to care. I did remove all listed locales (both requested and fallback) with zypper rloc and it has not changed anything on my system, other than zypper not wanting to install anyhting *-lang anymore. I still have lang packages installed for some gui tools, I just absolutely do not want to have localized cli tools and I do not want huge lang packages for just occasionally used GUI tools. "yast2 language" still says "primary language: German" "locale" as a user still has "LANG=de_DE.utf-8" -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman

Am 18.04.24 um 20:53 schrieb Felix Miata:

Stefan Seyfried composed on 2024-04-18 14:08 (UTC+0200):

...

The lock not breaking the update does show that these lang packages are only recommended and not required. But then why does "--no-recommends" not stop them from being installed?

I don't know. I don't normally use --no-recommends /flag/ with zypper, though I do deselect the enable recommends /option/ during installations. Instead I have:

# grep yReq /etc/zypp/zypp.conf solver.onlyRequires = true

That's technically the same as issuing "--no-recommends" on the command line. Sincs zypper still in 2024 is unable to deal with drop-in config files, I'm avoiding changes to zypp.conf as it will conflict with updates all the time and just put everything on the command line if possible.

# zypper ll | grep lang 3 | *-lang | package | (any) |

As I wrote, that's not a good workaround for my usecase, as I want *some* lang packages, but only a few. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman

On Fri, 2024-04-19 at 09:16 +0200, Johannes Meixner wrote:

I understand that every experienced user obviously always does it but as ultimately experienced user with final wisdom I learned following recommendations makes life easier (except exceptions)

I don't think consensus will ever be reached on this subject. Greetings from a strict "solver.onlyRequires = true" fanboy. Martin PS: Just checked out of curiosity, "zypper inr --recommends" would only install 165 additional packages on my workstation, occupying ~300MiB. That's much less than what it used to be - perhaps only texlive users must disable recommends these days.

* Martin Wilck via openSUSE Factory [04-19-24 05:38]:

On Fri, 2024-04-19 at 09:16 +0200, Johannes Meixner wrote:

...

I understand that every experienced user obviously always does it but as ultimately experienced user with final wisdom I learned following recommendations makes life easier (except exceptions)

I don't think consensus will ever be reached on this subject. Greetings from a strict "solver.onlyRequires = true" fanboy.

Martin

PS: Just checked out of curiosity, "zypper inr --recommends" would only install 165 additional packages on my workstation, occupying ~300MiB. That's much less than what it used to be - perhaps only texlive users must disable recommends these days.

"zypper inr --recommends" gets me: The following 10 NEW patterns are going to be installed: documentation 20200505-48.2 fonts 20170319-12.1 fonts_opt 20170319-12.1 kde_yast 20240311-2.1 multimedia 20201106-3.7 sw_management 20200505-48.2 x11_enhanced 20200505-48.2 x11_yast 20220411-1.6 yast2_basis 20220411-1.6 yast2_desktop 20220411-1.6 1155 new packages to install. Overall download size: 955.2 MiB. Already cached: 0 B. After the operation, additional 3.1 GiB will be used. a significant amount. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet oftc

* Robert Webb via openSUSE Factory [04-19-24 18:45]:

On Fri, 19 Apr 2024 09:16:26 -0400, Patrick Shanahan wrote:

...

* Martin Wilck via openSUSE Factory [04-19-24 05:38]:

...

On Fri, 2024-04-19 at 09:16 +0200, Johannes Meixner wrote:

...

I understand that every experienced user obviously always does it but as ultimately experienced user with final wisdom I learned following recommendations makes life easier (except exceptions)

I don't think consensus will ever be reached on this subject. Greetings from a strict "solver.onlyRequires = true" fanboy.

Martin

PS: Just checked out of curiosity, "zypper inr --recommends" would only install 165 additional packages on my workstation, occupying ~300MiB. That's much less than what it used to be - perhaps only texlive users must disable recommends these days.

"zypper inr --recommends" gets me:

   The following 10 NEW patterns are going to be installed:      documentation  20200505-48.2      fonts          20170319-12.1      fonts_opt      20170319-12.1      kde_yast       20240311-2.1      multimedia     20201106-3.7      sw_management  20200505-48.2      x11_enhanced   20200505-48.2      x11_yast       20220411-1.6      yast2_basis    20220411-1.6      yast2_desktop  20220411-1.6                            1155 new packages to install.    Overall download size: 955.2 MiB. Already cached: 0 B.  After the    operation, additional 3.1 GiB will be used.

a significant amount.

'zypper inr --no-recommends' is more limited but will still get you the *-lang packages.

...

From zypper(8):   "Called as zypper inr --no-recommends, it restricts the command to   just look for packages supporting available hardware, languages or   filesystems."

So what is the damage in that case? :-)

The following 12 NEW packages are going to be installed: accountsservice-lang gsettings-desktop-schemas-lang kcoreaddons-lang kf6-kcoreaddons-lang libKF5JobWidgets5-lang libKF5WidgetsAddons5-lang libKF6JobWidgets6-lang libKF6WidgetsAddons6-lang libvdpau_nouveau marble-lang openSUSE-repos-MicroOS-NVIDIA openSUSE-repos-Slowroll-NVIDIA 12 new packages to install. Overall download size: 31.0 MiB. Already cached: 0 B. After the operation, additional 60.4 MiB will be used. but I run Tumbleweed and speak/read English, so what need do I have for any Slowroll pgm or any of the cited lang packages? -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet oftc