[opensuse-factory] openSUSE is bloated! (Click-bait intentional)
Before you throw everything at me.... I Love openSUSE, it has one of if not THE the best package management tools available. But the problem is recommended packages. Y You must be tired of reading about this topic right? Today I spent the entire afternoon "cleaning-up" my Tumbleweed installation by removing a ton of packages I didn't installed/I don't use. I get that the default of installing recommended packages is all about user experience, but this has gone to far: - I had three display Managers installed, THREE! SDDM, LightDM, XDM. - I had a ton unneeded of 32bit libraries/binaries, yes I installed Wine, but I removed several libraries/binaries that weren't needed by Wine. I even had systemd-32bit installed! - I'm currently a ZSH user, but when I first installed Tumbleweed I had at least three shells installed (bash, zsh, tcsh) why?! And that's about things I specifically searched for deletion. I'm sure there's a lot more bloat hiding there. So, I'm nowhere near expert about packaging or about zypp/libzypp internals. But this is (kind of) what I propose: - Turn OFF "Recommended Packages" by default - If after this something is broken by missing packages, then those packages should be Dependencies not Recommendations. - Correct me here if I'm wrong, but patterns don't do anything unless the "Recommended Packages" setting is enabled. So, make the packages you want to be in the patterns as Dependencies not Recommendations. Again, I'm sure a lot I'm saying here is probably inaccurate. But I'm addressing a real issue here. I'm not surprised outside users form other distros say "openSUSE is bloated". In conclusion, this isn't just a childish rant. I really want to openSUSE to improve in this matter. I want to help too, please point me in the right direction. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On sob, cze 22, 2019 at 4:04 AM, Ignacio Taranto <itaranto7@gmail.com> wrote:
Before you throw everything at me....
I Love openSUSE, it has one of if not THE the best package management tools available.
But the problem is recommended packages. Y You must be tired of reading about this topic right?
Today I spent the entire afternoon "cleaning-up" my Tumbleweed installation by removing a ton of packages I didn't installed/I don't use.
I get that the default of installing recommended packages is all about user experience, but this has gone to far:
- I had three display Managers installed, THREE! SDDM, LightDM, XDM.
This is not an issue with recommends, you can't remove XDM even if you wanted to, because xdm holds the base scripts that start other stuff, because update-alternatives handling. Fixing that will require a little bit more than just removing recommends. This will certainly also make dropping Xorg from Factory in 50 years harder than it needs to be ;)
- I had a ton unneeded of 32bit libraries/binaries, yes I installed Wine, but I removed several libraries/binaries that weren't needed by Wine. I even had systemd-32bit installed!
I don't really see that looking at the zypper search results:
zypper se --recommends systemd-32bit
S | Name | Summary | Type --+----------------------------------+------------------------+-------- | patterns-base-minimal_base-32bit | Minimal Appliance Base | package | patterns-media-rest_cd_core | Remaining Software | package | patterns-media-rest_core_dvd | Remaining Software | package by the looks of it, those patterns are required or recommended by nothing, unless I'm missing something.
- I'm currently a ZSH user, but when I first installed Tumbleweed I had at least three shells installed (bash, zsh, tcsh) why?!
tcsh is required, not recommended by cvs: https://build.opensuse.org/package/view_file/openSUSE:Factory/cvs/cvs.spec cvs (and git-cvs) in turn is recommended by git, which is not installed by default with any default system role afaik.
And that's about things I specifically searched for deletion. I'm sure there's a lot more bloat hiding there.
So, I'm nowhere near expert about packaging or about zypp/libzypp internals. But this is (kind of) what I propose:
- Turn OFF "Recommended Packages" by default - If after this something is broken by missing packages, then those packages should be Dependencies not Recommendations. - Correct me here if I'm wrong, but patterns don't do anything unless the "Recommended Packages" setting is enabled. So, make the packages you want to be in the patterns as Dependencies not Recommendations.
This will break a few things, for example in case of branding packages, we don't really need to have branding elements installed on a server installation, so instead of using direct dependencies for the 'distribution-logos-openSUSE' packages (there are 4), recommends are used to install the correct one by the product packages. Now you might be asking, why isn't this handled with supplements, so differentiation between Kubic and MicroOS isn't done by the product package (they share the same one), but by different set of components, which means that if it was done through supplements, we would have a bunch of stuff conflicting with each other. You should probably talk with people that manage Kubic and MicroOS stuff though, I'm not enough of an expert in the area ;) And obviously, if anybody has a better idea, I'm open to anything, because that's just a mess :P
Again, I'm sure a lot I'm saying here is probably inaccurate. But I'm addressing a real issue here. I'm not surprised outside users form other distros say "openSUSE is bloated".
In conclusion, this isn't just a childish rant. I really want to openSUSE to improve in this matter. I want to help too, please point me in the right direction.
Changing zypp defaults wouldn't be that hard, they are all in libzypp repo: https://github.com/openSUSE/libzypp/blob/master/zypp.conf#L346-L354 I am actually curious, for the sake of cleaning dependencies, how far did implementing python dependency generator go? It would make cleaning up at least that side of the dependency problem a little easier. I wish more languages had dependency generators, some of the "typelib is missing" bugs with js applications is a little bit annoying ;) LCP [Stasiek] https://lcp.world -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Saturday, 22 June 2019 00:35:25 -03 Stasiek Michalski wrote:
This is not an issue with recommends, you can't remove XDM even if you wanted to, because xdm holds the base scripts that start other stuff, because update-alternatives handling. Fixing that will require a little bit more than just removing recommends. This will certainly also make dropping Xorg from Factory in 50 years harder than it needs to be ;) I told you I probably made some mistakes :)
But, I only installed KDE patterns and even so, I had both SDDM and LightDM. I think this is because lightdm is recommended by patterns-base-x11 which I have installed.
I don't really see that looking at the zypper search results:
zypper se --recommends systemd-32bit
S | Name | Summary | Type --+----------------------------------+------------------------+--------
| patterns-base-minimal_base-32bit | Minimal Appliance Base | package | patterns-media-rest_cd_core | Remaining Software | package | patterns-media-rest_core_dvd | Remaining Software | package
by the looks of it, those patterns are required or recommended by nothing, unless I'm missing something. Yes I checked that as well, I don't have those patterns installed.
- I'm currently a ZSH user, but when I first installed Tumbleweed I had at least three shells installed (bash, zsh, tcsh) why?!
tcsh is required, not recommended by cvs: https://build.opensuse.org/package/view_file/openSUSE:Factory/cvs/cvs.spec
cvs (and git-cvs) in turn is recommended by git, which is not installed by default with any default system role afaik. Yes that was git recommending cvs recommending tcsh.
This will break a few things, for example in case of branding packages, we don't really need to have branding elements installed on a server installation, so instead of using direct dependencies for the 'distribution-logos-openSUSE' packages (there are 4), recommends are used to install the correct one by the product packages. Now you might be asking, why isn't this handled with supplements, so differentiation between Kubic and MicroOS isn't done by the product package (they share the same one), but by different set of components, which means that if it was done through supplements, we would have a bunch of stuff conflicting with each other. You should probably talk with people that manage Kubic and MicroOS stuff though, I'm not enough of an expert in the area ;)
And obviously, if anybody has a better idea, I'm open to anything, because that's just a mess :P OK, for branding packages makes sense to not have "hard dependencies" but for all other patterns they do.
Also, I wasn't aware about Supplements or how do they work. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am Samstag, 22. Juni 2019, 19:30:31 CEST schrieb Ignacio Taranto:
On Saturday, 22 June 2019 00:35:25 -03 Stasiek Michalski wrote:
[...]
- I'm currently a ZSH user, but when I first installed Tumbleweed I had at least three shells installed (bash, zsh, tcsh) why?!
tcsh is required, not recommended by cvs: https://build.opensuse.org/package/view_file/openSUSE:Factory/cvs/cvs.spec
cvs (and git-cvs) in turn is recommended by git, which is not installed by default with any default system role afaik.
Yes that was git recommending cvs recommending tcsh.
That's a point where some packages are really wrong. Instead of requiring git-core what's enough or most packages using git, the whole git meta package is required, which in turn recommends git-cvs, git-svn, git-web and gti-daemon and their dependencies. I think, some "Requires: git" can be changed to "Requires: git-core" and the package git-svn shall only be pulled if svn has been chosen by the user, too. The same for git-cvs.
[...]
Herbert -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 23/06/2019 04:49, Herbert Graeber wrote:
Am Samstag, 22. Juni 2019, 19:30:31 CEST schrieb Ignacio Taranto:
On Saturday, 22 June 2019 00:35:25 -03 Stasiek Michalski wrote:
[...]
- I'm currently a ZSH user, but when I first installed Tumbleweed I had at least three shells installed (bash, zsh, tcsh) why?!
tcsh is required, not recommended by cvs: https://build.opensuse.org/package/view_file/openSUSE:Factory/cvs/cvs.spec
cvs (and git-cvs) in turn is recommended by git, which is not installed by default with any default system role afaik.
Yes that was git recommending cvs recommending tcsh.
That's a point where some packages are really wrong.
Instead of requiring git-core what's enough or most packages using git, the whole git meta package is required, which in turn recommends git-cvs, git-svn, git-web and gti-daemon and their dependencies.
I think, some "Requires: git" can be changed to "Requires: git-core" and the package git-svn shall only be pulled if svn has been chosen by the user, too. The same for git-cvs.
Id tend to agree, but i'm not going to do it today and am likely to forget, so file a bug on the patterns and i'll fix it sometime after hackweek, as the person now looking after the patterns I don't know the in's and outs of every package in the distro so feedback like this is really useful. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 23/06/2019 07.22, Simon Lees wrote:
On 23/06/2019 04:49, Herbert Graeber wrote:
Am Samstag, 22. Juni 2019, 19:30:31 CEST schrieb Ignacio Taranto:
On Saturday, 22 June 2019 00:35:25 -03 Stasiek Michalski wrote:
[...]
- I'm currently a ZSH user, but when I first installed Tumbleweed I had at least three shells installed (bash, zsh, tcsh) why?!
tcsh is required, not recommended by cvs: https://build.opensuse.org/package/view_file/openSUSE:Factory/cvs/cvs.spec
cvs (and git-cvs) in turn is recommended by git, which is not installed by default with any default system role afaik.
Yes that was git recommending cvs recommending tcsh.
That's a point where some packages are really wrong.
Instead of requiring git-core what's enough or most packages using git, the whole git meta package is required, which in turn recommends git-cvs, git-svn, git-web and gti-daemon and their dependencies.
I think, some "Requires: git" can be changed to "Requires: git-core" and the package git-svn shall only be pulled if svn has been chosen by the user, too. The same for git-cvs.
Id tend to agree, but i'm not going to do it today and am likely to forget, so file a bug on the patterns and i'll fix it sometime after hackweek, as the person now looking after the patterns I don't know the in's and outs of every package in the distro so feedback like this is really useful.
For when you find time: echo `grep '^Requires: *git$' */*.spec|cut -d/ -f1` cookiecutter gitolite git-remote-gcrypt guilt hg-fast-export holodev mycroft-core python-nbdime submin svn2git vim-bootstrap and then there are also 62 BuildRequires that are probably even less correct: biboumi bitcoin bubblewrap buildah cilium cilium-proxy cilium-proxy cilium-proxy compton cookiecutter dex-oidc dmd envoy-proxy envoy-proxy envoy-proxy erlang-rebar erlang-rebar erlang-rebar-testsuite erlang-rebar-testsuite exa execstack fontforge form FreeCAD gitolite goldendict grubby hawk2 holodev istio-proxy istio-proxy istio-proxy kbfs kubernetes kubernetes lucene mercurial meson modsecurity neko openafs password-store pepper powdertoy python-GitPython python-pip python-python-coveralls python-reno python-translationstring quassel racer rawstudio rust scons slirp4netns strawberry svgcleaner trojita vala-panel-appmenu vim-bootstrap vpp way-cooler git-svn could replace the Recommends with a line in the subpackage: Supplements: packageand(git-core:subversion) so it will only be recommended when you have both. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tuesday 2019-06-25 10:17, Bernhard M. Wiedemann wrote:
and then there are also 62 BuildRequires [on git] that are probably even less correct: biboumi bitcoin bubblewrap buildah cilium cilium-proxy cilium-proxy [..]
There is sometimes shitty software that tries to run git commands during configure/etc., and in doing so, cannot deal with the absence of the git software, but very well the absence of the ".git" repository. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 23/06/2019 03:00, Ignacio Taranto wrote:
On Saturday, 22 June 2019 00:35:25 -03 Stasiek Michalski wrote:
This is not an issue with recommends, you can't remove XDM even if you wanted to, because xdm holds the base scripts that start other stuff, because update-alternatives handling. Fixing that will require a little bit more than just removing recommends. This will certainly also make dropping Xorg from Factory in 50 years harder than it needs to be ;) I told you I probably made some mistakes :)
But, I only installed KDE patterns and even so, I had both SDDM and LightDM. I think this is because lightdm is recommended by patterns-base-x11 which I have installed.
Yeah once someone has time to fix xdm, patterns-base-x11 will change to recommend "display-manager" and will only suggest lightdm, at that point you will only get one display manager. On the plus side soon you won't also get icewm installed. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Simon Lees composed on 2019-06-23 15:06 (UTC+0930):
Yeah once someone has time to fix xdm, patterns-base-x11 will change to recommend "display-manager" and will only suggest lightdm, at that point you will only get one display manager. On the plus side soon you won't also get icewm installed.
On the plus side for forums and mailing list support participants? Ironic to learn in this subthread about this particular saving. Requesting selection of IceWM instead of Gnome or Plasma from the login manager is the easiest way to find out whether some n00b's video problem has the DE or X at fault. It's a bad time to suggest they install more software in order to debug their problem, e.g.: https://forums.opensuse.org/showthread.php/536427-Could-my-graphics-adaptor-... -> https://forums.opensuse.org/showthread.php/536501-Recent-update-of-Plasma-KD... -- Evolution as taught in public schools is religion, not science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 23/06/2019 16:13, Felix Miata wrote:
Simon Lees composed on 2019-06-23 15:06 (UTC+0930):
Yeah once someone has time to fix xdm, patterns-base-x11 will change to recommend "display-manager" and will only suggest lightdm, at that point you will only get one display manager. On the plus side soon you won't also get icewm installed.
On the plus side for forums and mailing list support participants? Ironic to learn in this subthread about this particular saving. Requesting selection of IceWM instead of Gnome or Plasma from the login manager is the easiest way to find out whether some n00b's video problem has the DE or X at fault. It's a bad time to suggest they install more software in order to debug their problem, e.g.: https://forums.opensuse.org/showthread.php/536427-Could-my-graphics-adaptor-... -> https://forums.opensuse.org/showthread.php/536501-Recent-update-of-Plasma-KD...
Yep and welcome to the "fun" of this topic, when people complain about bloated software, generally the two most common complaints are xdm+lightdm / icewm. Maybe we can come up with a patterns-base-support, containing a list of packages that are useful for diagnosing systems with issues, i get the point that icewm is not the easiest to install without a pattern. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hi, Depending on when you last did a clean install its probably already somewhat better, we went through a while back and took a bunch of stuff out of the patterns so in some areas its probably already now better. On 22/06/2019 11:34, Ignacio Taranto wrote:
Before you throw everything at me....
I Love openSUSE, it has one of if not THE the best package management tools available.
But the problem is recommended packages. Y You must be tired of reading about this topic right?
Today I spent the entire afternoon "cleaning-up" my Tumbleweed installation by removing a ton of packages I didn't installed/I don't use.
I get that the default of installing recommended packages is all about user experience, but this has gone to far:
- I had three display Managers installed, THREE! SDDM, LightDM, XDM.
In the latest submission you should be back to getting SDDM or LightDM rather then both on default installs. xdm is still needed as mentioned in the other thread.
- I had a ton unneeded of 32bit libraries/binaries, yes I installed Wine, but I removed several libraries/binaries that weren't needed by Wine. I even had systemd-32bit installed!
If you ever have a 32bit pattern installed it will give you a 32bit version of all the libraries in that pattern that you can.
- I'm currently a ZSH user, but when I first installed Tumbleweed I had at least three shells installed (bash, zsh, tcsh) why?!
I think we improved this as well, there are a bunch of scripts that need bash and it provides /bin/sh from memory tcsh is no longer pulled in.
And that's about things I specifically searched for deletion. I'm sure there's a lot more bloat hiding there.
So, I'm nowhere near expert about packaging or about zypp/libzypp internals. But this is (kind of) what I propose:
- Turn OFF "Recommended Packages" by default
In the past we have had feedback from many people that they like the fact that they have everything they need out of the box especially on desktop systems, obviously that's the opposite of what you want. If we get it to the point of working well potentially we could look at a minimal system role that has recommends disabled
- If after this something is broken by missing packages, then those packages should be Dependencies not Recommendations. - Correct me here if I'm wrong, but patterns don't do anything unless the "Recommended Packages" setting is enabled. So, make the packages you want to be in the patterns as Dependencies not Recommendations.
The patterns will do something with recommends disabled, however the something is known to lead to broken systems particularly on desktops mostly due to certain things being recommended that should be required, once you get out of the core patterns, no recommends and patterns do start to make less sense, for example if you just install the enlightenment package, you'll get a working desktop if you install the pattern with no recommends you should get basically the same thing, if you install it with recommends however, you'll get a browser and some other basic desktop apps, because people complained it didn't have these things..
Again, I'm sure a lot I'm saying here is probably inaccurate. But I'm addressing a real issue here. I'm not surprised outside users form other distros say "openSUSE is bloated".
Recommends Vs Requires can be clear cut and there is some places we get it wrong but there are many other places where its much less clear cut, for example, there are many places where a program might not strictly need a plugin / dependency but without that feature working most users would complain that the program is broken or not useful, in such cases maintainers have probably decided to go with requires over recommends, in other cases they may not have.
In conclusion, this isn't just a childish rant. I really want to openSUSE to improve in this matter. I want to help too, please point me in the right direction.
A start would be firing up a VM then customizing your install to only install the base pattern, then boot in disable recommends, install the rest of the system the way you want then start fixing the stuff that's broken because recommends should be requires. Then I guess start looking at some other desktops / systems you wouldn't normally use and see if you find issues there. Once you know its working adding some openQA tests with no recommends would be great. Really the biggest reason this isn't better in openSUSE atm is because no one who cares about it has put the effort in to make it better, beyond the base system anyway, that has had some work to make it better for containers etc. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
In the latest submission you should be back to getting SDDM or LightDM rather then both on default installs. xdm is still needed as mentioned in the other thread.
On Sat, 22 Jun 2019 at 04:40, Simon Lees <sflees@suse.de> wrote: lightdm is recommended by patterns-base-x11 which is present when you select the "KDE Dekstop" configuration.
If you ever have a 32bit pattern installed it will give you a 32bit version of all the libraries in that pattern that you can. That's correct by I don't have any 32bit pattern, as far as I remember, the only package I have that requires 32bit pakcages is wine.
In the past we have had feedback from many people that they like the fact that they have everything they need out of the box especially on desktop systems, obviously that's the opposite of what you want. If we get it to the point of working well potentially we could look at a minimal system role that has recommends disabled Yes I agree with that, everything should work "out of the box" specially when it comes to desktop, but there's also an unnecessary amount of recommended patterns that get pulled. And installing a system (for desktop use or not) is somehow broken if you disable recommended packages during the installation.
The patterns will do something with recommends disabled, however the something is known to lead to broken systems particularly on desktops mostly due to certain things being recommended that should be required, once you get out of the core patterns, no recommends and patterns do start to make less sense, for example if you just install the enlightenment package, you'll get a working desktop if you install the pattern with no recommends you should get basically the same thing, if you install it with recommends however, you'll get a browser and some other basic desktop apps, because people complained it didn't have these things.. I checked that for patterns like enlightenment an other desktops some packages get installed event with recommended packages disabled. However there are other patters that don't do anything when that option is turned off.
Recommends Vs Requires can be clear cut and there is some places we get it wrong but there are many other places where its much less clear cut, for example, there are many places where a program might not strictly need a plugin / dependency but without that feature working most users would complain that the program is broken or not useful, in such cases maintainers have probably decided to go with requires over recommends, in other cases they may not have. Yes, I realize this is sort of a grey area. But, like you said, maybe it should be up to the maintainers to decide which are "true" dependencies and which are not. So that, disabling recommend packages will be acceptable.
A start would be firing up a VM then customizing your install to only install the base pattern, then boot in disable recommends, install the rest of the system the way you want then start fixing the stuff that's broken because recommends should be requires. Then I guess start looking at some other desktops / systems you wouldn't normally use and see if you find issues there. Once you know its working adding some openQA tests with no recommends would be great.
Really the biggest reason this isn't better in openSUSE atm is because no one who cares about it has put the effort in to make it better, beyond the base system anyway, that has had some work to make it better for containers etc. Good suggestion. Will do. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 22/06/2019 04.04, Ignacio Taranto wrote:
- Turn OFF "Recommended Packages" by default
The problem is that this affects non-core features of applications. A program can fail to do something and it is unclear that it is because some recommended package was not installed. For example, about a month ago there was a thread about a new line in /etc/pam.d/su using wheel failed because recommended package system-group-wheel was not installed. Disabling "Recommended Packages" can bite you back. Of course, an application could perhaps notice what is not installed and say so when trying to use a feature that needs it. But not all apps can. -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)
On 6/22/19 6:42 PM, Carlos E. R. wrote:
On 22/06/2019 04.04, Ignacio Taranto wrote:
- Turn OFF "Recommended Packages" by default
The problem is that this affects non-core features of applications. A program can fail to do something and it is unclear that it is because some recommended package was not installed.
For example, about a month ago there was a thread about a new line in /etc/pam.d/su using wheel failed because recommended package system-group-wheel was not installed.
Disabling "Recommended Packages" can bite you back.
Of course, an application could perhaps notice what is not installed and say so when trying to use a feature that needs it. But not all apps can.
In such cases shouldn't it be a "Required" package instead? I don't quite understand why use "Recommends" if the dependency is necessary for a program to function properly. -- Maurizio Galli (MauG) Xfce Team https://en.opensuse.org/Portal:Xfce -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Saturday, 2019-06-22 at 21:15 +0800, Maurizio Galli (MauG) wrote:
On 6/22/19 6:42 PM, Carlos E. R. wrote:
On 22/06/2019 04.04, Ignacio Taranto wrote:
- Turn OFF "Recommended Packages" by default
The problem is that this affects non-core features of applications. A program can fail to do something and it is unclear that it is because some recommended package was not installed.
For example, about a month ago there was a thread about a new line in /etc/pam.d/su using wheel failed because recommended package system-group-wheel was not installed.
Disabling "Recommended Packages" can bite you back.
Of course, an application could perhaps notice what is not installed and say so when trying to use a feature that needs it. But not all apps can.
In such cases shouldn't it be a "Required" package instead? I don't quite understand why use "Recommends" if the dependency is necessary for a program to function properly.
Because it is not necesary for the normal or default functionality. If you install recommended packages, you get all. It is an acceptable compromise, IMO. An application with plugins can request adding whatever plugin. But many others can't, don't have such a mechanism. - -- Cheers, Carlos E. R. (from openSUSE 15.0 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCXQ4xAxwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfVaI4AniDrLtBziP1ztNfakqIc mXtQqBp/AKCMPM56c33dKbpspczM/HicOuhUzQ== =cGot -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Sat, Jun 22, Maurizio Galli (MauG) wrote:
On 6/22/19 6:42 PM, Carlos E. R. wrote:
Of course, an application could perhaps notice what is not installed and say so when trying to use a feature that needs it. But not all apps can.
In such cases shouldn't it be a "Required" package instead? I don't quite understand why use "Recommends" if the dependency is necessary for a program to function properly.
Because it is not necessary. Back to the pam_wheel/sudo problem: the group wheel is not needed for standard configuration. It's an optional, nice to have feature. And we introduced Recommends to be not required to use Requires for optional, nice to have features. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendoerffer, Mary Higgins, Sri Rasiah, HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 6/22/19 3:15 PM, Maurizio Galli (MauG) wrote:
On 6/22/19 6:42 PM, Carlos E. R. wrote:
On 22/06/2019 04.04, Ignacio Taranto wrote:
- Turn OFF "Recommended Packages" by default
The problem is that this affects non-core features of applications. A program can fail to do something and it is unclear that it is because some recommended package was not installed.
For example, about a month ago there was a thread about a new line in /etc/pam.d/su using wheel failed because recommended package system-group-wheel was not installed.
Disabling "Recommended Packages" can bite you back.
Of course, an application could perhaps notice what is not installed and say so when trying to use a feature that needs it. But not all apps can.
In such cases shouldn't it be a "Required" package instead?
In this particular case: No. Because a system could have a completely different sudoers file not using wheel group at all. E.g. On systems with fairly high security requirements you want to remove the wheel group often abused for privileged side access.
I don't quite understand why use "Recommends" if the dependency is necessary for a program to function properly. There is a huge difference between a dependency to make a program work or an optional dependency to make a an optional default config work (like default sudoers file).
Ciao, Michael.
On Saturday 2019-06-22 15:15, Maurizio Galli (MauG) wrote:
Of course, an application could perhaps notice what is not installed and say so when trying to use a feature that needs it. But not all apps can.
In such cases shouldn't it be a "Required" package instead? I don't quite understand why use "Recommends" if the dependency is necessary for a program to function properly.
Because "proper" is in the eye of the beholder. I expect evince to read PDFs, so I need evince-plugin-pdfdocument.rpm, but another person may expect it to read DJVU (which I don't care about), so they need evince-plugin-djvudocument.rpm. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Il giorno Fri, 21 Jun 2019 23:04:18 -0300 Ignacio Taranto <itaranto7@gmail.com> ha scritto:
- Turn OFF "Recommended Packages" by default - If after this something is broken by missing packages, then those packages should be Dependencies not Recommendations.
-1. Recommends are optional (but recommended) dependencies. They're not hard-required for packages. People already break their desktops when they think that removing recommends is a good idea. I would not welcome more bug reports like that. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Fri, 21 Jun 2019 23:04:18 -0300, Ignacio Taranto <itaranto7@gmail.com> wrote:
- I'm currently a ZSH user, but when I first installed Tumbleweed I had at least three shells installed (bash, zsh, tcsh) why?!
1. Because they are small 2. Because they are used. *YOU* (as an end user) use zsh, which is fine, but many parts of the system *require* bash to be around If you have a problem on your system and ask a friend to help out, and he/she needs to dig, he/she will most likely start their fav shell first. zsh is a fine shell, but others may prefer bash or tcsh. (I belong to the ones that us tcsh as my base shell, but *not* for scripting, for which I use sh (any POSIX compliant) or perl) 3. Because you might not be the only user If you add your friend/child/partner to your system, they might prefer one of the alternatives, and bash is - like it or not - the de-facto default shell for users on Linux. New users expect that. Look in /etc/shells to see that you have probably more than 3: /bin/ash /bin/bash /bin/csh /bin/dash /bin/false /bin/ksh /bin/ksh93 /bin/mksh /bin/pdksh /bin/sh /bin/tcsh /bin/true /bin/zsh /usr/bin/csh /usr/bin/dash /usr/bin/ksh /usr/bin/ksh93 /usr/bin/mksh /usr/bin/passwd /usr/bin/pdksh /usr/bin/bash /usr/bin/tcsh /usr/bin/zsh /usr/bin/fish -- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using perl5.00307 .. 5.29 porting perl5 on HP-UX, AIX, and openSUSE http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/ http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
1. Because they are small
2. Because they are used.
*YOU* (as an end user) use zsh, which is fine, but many parts of the system *require* bash to be around
If you have a problem on your system and ask a friend to help out, and he/she needs to dig, he/she will most likely start their fav shell first. zsh is a fine shell, but others may prefer bash or tcsh. (I belong to the ones that us tcsh as my base shell, but *not* for scripting, for which I use sh (any POSIX compliant) or perl)
3. Because you might not be the only user
If you add your friend/child/partner to your system, they might prefer one of the alternatives, and bash is - like it or not - the de-facto default shell for users on Linux. New users expect that.
Look in /etc/shells to see that you have probably more than 3:
/bin/ash /bin/bash /bin/csh /bin/dash /bin/false /bin/ksh /bin/ksh93 /bin/mksh /bin/pdksh /bin/sh /bin/tcsh /bin/true /bin/zsh /usr/bin/csh /usr/bin/dash /usr/bin/ksh /usr/bin/ksh93 /usr/bin/mksh /usr/bin/passwd /usr/bin/pdksh /usr/bin/bash /usr/bin/tcsh /usr/bin/zsh /usr/bin/fish I wasn't saying that bash shouldn't be installed if I use something else. I do know that bash is the default shell and it would break a lot of
On Sat, 22 Jun 2019 at 10:52, H.Merijn Brand <h.m.brand@xs4all.nl> wrote: things if it gets removed. I said that after installing a desktop and a couple of packages you will get some additional shells like zsh, tcsh, and that's not probably what you want. Again, this was just an example to show about random things that get installed because of the default zypp settings. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
In my opinion, openSUSE is not the distro for users wanting their software taking the minimal disk space possible with everything not needed perceived as "bloat" that has to be removed. It's just not a minimal distro. You can try if you wish blocking packages and stuff at the expense of it taking a lot of your time and the possiblity of breaking stuff for what...saving 1 or 2GB of disk space with the fuzzy feeling of duty achieved ? Or you can just relax and don't care an let the system do its stuff. The only case where I locked packages is texlive as > 1000 packages for it is a bit too much, or if I install manually a program that conflicts with a package. That is not to say some improvement can be made in term of dependencies. But I quite like that each installed package is full featured. On 6/22/19 4:04 AM, Ignacio Taranto wrote:
Before you throw everything at me....
I Love openSUSE, it has one of if not THE the best package management tools available.
But the problem is recommended packages. Y You must be tired of reading about this topic right?
Today I spent the entire afternoon "cleaning-up" my Tumbleweed installation by removing a ton of packages I didn't installed/I don't use.
I get that the default of installing recommended packages is all about user experience, but this has gone to far:
- I had three display Managers installed, THREE! SDDM, LightDM, XDM. - I had a ton unneeded of 32bit libraries/binaries, yes I installed Wine, but I removed several libraries/binaries that weren't needed by Wine. I even had systemd-32bit installed! - I'm currently a ZSH user, but when I first installed Tumbleweed I had at least three shells installed (bash, zsh, tcsh) why?!
And that's about things I specifically searched for deletion. I'm sure there's a lot more bloat hiding there.
So, I'm nowhere near expert about packaging or about zypp/libzypp internals. But this is (kind of) what I propose:
- Turn OFF "Recommended Packages" by default - If after this something is broken by missing packages, then those packages should be Dependencies not Recommendations. - Correct me here if I'm wrong, but patterns don't do anything unless the "Recommended Packages" setting is enabled. So, make the packages you want to be in the patterns as Dependencies not Recommendations.
Again, I'm sure a lot I'm saying here is probably inaccurate. But I'm addressing a real issue here. I'm not surprised outside users form other distros say "openSUSE is bloated".
In conclusion, this isn't just a childish rant. I really want to openSUSE to improve in this matter. I want to help too, please point me in the right direction.
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Sat, 22 Jun 2019 at 11:04, Michael Pujos <pujos.michael@gmail.com> wrote:
In my opinion, openSUSE is not the distro for users wanting their software taking the minimal disk space possible with everything not needed perceived as "bloat" that has to be removed. It's just not a minimal distro.
You can try if you wish blocking packages and stuff at the expense of it taking a lot of your time and the possiblity of breaking stuff for what...saving 1 or 2GB of disk space with the fuzzy feeling of duty achieved ? Or you can just relax and don't care an let the system do its stuff.
The only case where I locked packages is texlive as > 1000 packages for it is a bit too much, or if I install manually a program that conflicts with a package.
That is not to say some improvement can be made in term of dependencies. But I quite like that each installed package is full featured.
If you have a laptop with a small disk, let's say 128 or 256 GB, space *will* matter. Having a bunch of things you don't use/need is inefficient. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 22/06/2019 20:02, Ignacio Taranto wrote:
If you have a laptop with a small disk, let's say 128 or 256 GB, space *will* matter. Having a bunch of things you don't use/need is inefficient.
If you are so low on storage to care about that, you will probably not use btrfs and snapshots, so we can remove that from the discussion. Currently my install takes about 17GB (not taking into account snapshots) for about 3300 packages. At best. if I were to trim the package I do not need, I could probaby gain a few GB with a lot of effort, micro-managing stuff. But is that really worth it ? Not in my opinion. Does having a lot of packages you do not use slow down the system ? I don't think so as it is not going to affect startup times significantly. Though it can be painful if you have a slow internet connection. That being said, it would still be good to have a mode of operation of the distro that can keep things fairly minimal without the fear of breaking stuff. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Does having a lot of packages you do not use slow down the system ? I No, unless the additional unwanted packages contains services enabled by default (do not know an example about this, but it could be
On Sat, 22 Jun 2019 at 15:26, Michael Pujos <pujos.michael@gmail.com> wrote: possible). But I'm sure as hell it slows down updates. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am Montag, 24. Juni 2019, 15:06:43 CEST schrieb Ignacio Taranto:
On Sat, 22 Jun 2019 at 15:26, Michael Pujos <pujos.michael@gmail.com> wrote:
Does having a lot of packages you do not use slow down the system ? I
No, unless the additional unwanted packages contains services enabled by default (do not know an example about this, but it could be possible). But I'm sure as hell it slows down updates.
Speaking of bloat: $ du -sh /usr/share/locale/ 811M /usr/share/locale/ This is a thinkPad X1 (*rev1*), that is severely space constraint... Pete -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, 24 Jun 2019 17:04:11 +0200, Hans-Peter Jansen <hpj@urpla.net> wrote:
Am Montag, 24. Juni 2019, 15:06:43 CEST schrieb Ignacio Taranto:
On Sat, 22 Jun 2019 at 15:26, Michael Pujos <pujos.michael@gmail.com> wrote:
Does having a lot of packages you do not use slow down the system ? I
No, unless the additional unwanted packages contains services enabled by default (do not know an example about this, but it could be possible). But I'm sure as hell it slows down updates.
Speaking of bloat:
$ du -sh /usr/share/locale/ 811M /usr/share/locale/
Worse openSUSE Tumbleweed 20190621 $ du -sh /usr/share/locale/ 1.3G /usr/share/locale/ And I would love an option to *not* install Thai, Japanese, Chinese and other locales and localized messages that I won't use. Not that I mind on my development laptop, but having this on servers in the cloud rapidly adds to the total space and if the server is known to only need say English and Dutch (or whatever language the server is to support) having all the others is a bit of a burden on the disk space (and thus the backups/snapshots) FWIW this is not a new problem. I've seen it with e.g. HP-UX that by default came with all supported locales installed (way less than what Linux supports) and I had to remove all those Asian locales before I had enough disk-space to install packages I *did* need. I do understand the need for all those locales on install, where people choose the language the want to install the distribution in, but a (new) option to exclude (groups of) locales would be welcomed IMHO.
This is a thinkPad X1 (*rev1*), that is severely space constraint...
Pete
-- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using perl5.00307 .. 5.29 porting perl5 on HP-UX, AIX, and openSUSE http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/ http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
On Mon, 24 Jun 2019 17:25:37 +0200 "H.Merijn Brand" <h.m.brand@xs4all.nl> wrote:
On Mon, 24 Jun 2019 17:04:11 +0200, Hans-Peter Jansen <hpj@urpla.net> wrote:
Am Montag, 24. Juni 2019, 15:06:43 CEST schrieb Ignacio Taranto:
On Sat, 22 Jun 2019 at 15:26, Michael Pujos <pujos.michael@gmail.com> wrote:
Does having a lot of packages you do not use slow down the system ? I
No, unless the additional unwanted packages contains services enabled by default (do not know an example about this, but it could be possible). But I'm sure as hell it slows down updates.
Speaking of bloat:
$ du -sh /usr/share/locale/ 811M /usr/share/locale/
Worse
openSUSE Tumbleweed 20190621 $ du -sh /usr/share/locale/ 1.3G /usr/share/locale/
And I would love an option to *not* install Thai, Japanese, Chinese and other locales and localized messages that I won't use. Not that I mind on my development laptop, but having this on servers in the cloud rapidly adds to the total space and if the server is known to only need say English and Dutch (or whatever language the server is to support) having all the others is a bit of a burden on the disk space (and thus the backups/snapshots)
FWIW this is not a new problem. I've seen it with e.g. HP-UX that by default came with all supported locales installed (way less than what Linux supports) and I had to remove all those Asian locales before I had enough disk-space to install packages I *did* need.
I do understand the need for all those locales on install, where people choose the language the want to install the distribution in, but a (new) option to exclude (groups of) locales would be welcomed IMHO.
The locale definitions are much smaller than the generated locales. An alternative that some distributions do is generating only selected locales (ie the ones the user selected on installation). This saves a lot of space and bandwidth but is very time-consuming (ie on Raspberry Pi). An additional improvement to that is - select locales to generate/install - select either full pre-generated locales package or definition-only package for which the selected locales are generated on installation However, that's more options to test and support. Thanks Michal
On Jun 24 2019, Michal Suchánek <msuchanek@suse.de> wrote:
The locale definitions are much smaller than the generated locales.
/usr/share/locale contains the translations (*-lang packages), not the locales. Andreas. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, 24 Jun 2019 17:50:19 +0200 Andreas Schwab <schwab@suse.de> wrote:
On Jun 24 2019, Michal Suchánek <msuchanek@suse.de> wrote:
The locale definitions are much smaller than the generated locales.
/usr/share/locale contains the translations (*-lang packages), not the locales.
Andreas.
Indeed, the locales are in /usr/lib/locale and take 116M (except LC_TIME is stuffed in /usr/share/locale at least in some cases for some reason) . If you have a lot of translated messages that is proportional to a the amount of applications installed. The translated messages are typically small compared to the application. In this case packaging the translation separately is not going to be effective. Exceptions do exist - ie OpenOffice used to do language-specific builds of large parts of the application to be able to offer more locale-specific customization (possibly UI layout and graphics) rather than plain message translation. Thanks Michal -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, 24 Jun 2019 18:13:17 +0200, Michal Suchánek <msuchanek@suse.de> wrote:
On Mon, 24 Jun 2019 17:50:19 +0200 Andreas Schwab <schwab@suse.de> wrote:
On Jun 24 2019, Michal Suchánek <msuchanek@suse.de> wrote:
The locale definitions are much smaller than the generated locales.
/usr/share/locale contains the translations (*-lang packages), not the locales.
$ du -sh /usr/lib/locale 222M /usr/lib/locale (out of which less than 5 Mb is used for en + nl) The more reason to be able to filter installed parts of -lang packages on "used locales". I've just selected (recursively) what TW would use in /usr/share/locale if I just want en, en_US, and Dutch, and that sums to ± 28Mb, which means that a mere 2% of that disk space will actually be used
Andreas.
Indeed, the locales are in /usr/lib/locale and take 116M (except LC_TIME is stuffed in /usr/share/locale at least in some cases for some reason) . If you have a lot of translated messages that is proportional to a the amount of applications installed. The translated messages are typically small compared to the application. In this case packaging the translation separately is not going to be effective.
Exceptions do exist - ie OpenOffice used to do language-specific builds of large parts of the application to be able to offer more locale-specific customization (possibly UI layout and graphics) rather than plain message translation.
And HTML (in many languages), which I have never ever (knowingly) used: $ du -sh /usr/share/doc/HTML 298M /usr/share/doc/HTML FWIW I fully support packages/products to translate their product into as many languages as possible: it lowers the threshold for many to use these open-source products. I also know it takes an awful lot of time of volunteers to make *and maintain* these translations. In summary, I rather have all translations of the products I choose to install, including those that I don't care about, than have products that put their time (and effort) into creating options to skip unwanted locales. They have better things to do. Maybe we just need a new "tool" that cleans up the system of unwanted locales and parts of -lang packages after an installation of update has finished.
Michal
-- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using perl5.00307 .. 5.29 porting perl5 on HP-UX, AIX, and openSUSE http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/ http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
On Mon, 24 Jun 2019 18:38:45 +0200, H.Merijn Brand wrote:
On Mon, 24 Jun 2019 18:13:17 +0200, Michal Suchánek <msuchanek@suse.de> wrote:
On Mon, 24 Jun 2019 17:50:19 +0200 Andreas Schwab <schwab@suse.de> wrote:
On Jun 24 2019, Michal Suchánek <msuchanek@suse.de> wrote:
The locale definitions are much smaller than the generated locales.
/usr/share/locale contains the translations (*-lang packages), not the locales.
$ du -sh /usr/lib/locale 222M /usr/lib/locale
(out of which less than 5 Mb is used for en + nl)
The more reason to be able to filter installed parts of -lang packages on "used locales".
I've just selected (recursively) what TW would use in /usr/share/locale if I just want en, en_US, and Dutch, and that sums to ± 28Mb, which means that a mere 2% of that disk space will actually be used
Andreas.
Indeed, the locales are in /usr/lib/locale and take 116M (except LC_TIME is stuffed in /usr/share/locale at least in some cases for some reason) . If you have a lot of translated messages that is proportional to a the amount of applications installed. The translated messages are typically small compared to the application. In this case packaging the translation separately is not going to be effective.
Exceptions do exist - ie OpenOffice used to do language-specific builds of large parts of the application to be able to offer more locale-specific customization (possibly UI layout and graphics) rather than plain message translation.
And HTML (in many languages), which I have never ever (knowingly) used: $ du -sh /usr/share/doc/HTML 298M /usr/share/doc/HTML
FWIW I fully support packages/products to translate their product into as many languages as possible: it lowers the threshold for many to use these open-source products. I also know it takes an awful lot of time of volunteers to make *and maintain* these translations.
In summary, I rather have all translations of the products I choose to install, including those that I don't care about, than have products that put their time (and effort) into creating options to skip unwanted locales. They have better things to do.
Maybe we just need a new "tool" that cleans up the system of unwanted locales and parts of -lang packages after an installation of update has finished.
Or need to split to subpackages per language? With a help of rpm macro, it shouldn't be too hard. I can think of a macro like KMP builds. Maybe the most difficult part is to know the language list before the package build itself... thanks, Takashi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
24.06.2019 20:21, Takashi Iwai пишет:
Or need to split to subpackages per language?
With a help of rpm macro, it shouldn't be too hard. I can think of a macro like KMP builds. Maybe the most difficult part is to know the language list before the package build itself...
Mandrake rpm supported partial installation of language components in package according to configured list. So selecting "en ru de" as list of languages resulted in installing only these translations. It was long ago, but I do not think it used subpackages, rather somehow tagged files (may be based on fixed location, like /usr/share/locale/$LANG). -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, 24 Jun 2019 19:46:32 +0200, Andrei Borzenkov wrote:
24.06.2019 20:21, Takashi Iwai пишет:
Or need to split to subpackages per language?
With a help of rpm macro, it shouldn't be too hard. I can think of a macro like KMP builds. Maybe the most difficult part is to know the language list before the package build itself...
Mandrake rpm supported partial installation of language components in package according to configured list. So selecting "en ru de" as list of languages resulted in installing only these translations. It was long ago, but I do not think it used subpackages, rather somehow tagged files (may be based on fixed location, like /usr/share/locale/$LANG).
Aha, that's an interesting approach. But what happens if you enable one more language support on the running system? Would the already installed packages need to be re-installed? A sub-package approach would be more flexible in that regard. But it wastes a few more resources for package meta data, and the whole package list may become messier, which are a clear down side. thanks, Takashi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 25/06/2019 03:53, Takashi Iwai wrote:
On Mon, 24 Jun 2019 19:46:32 +0200, Andrei Borzenkov wrote:
24.06.2019 20:21, Takashi Iwai пишет:
Or need to split to subpackages per language?
With a help of rpm macro, it shouldn't be too hard. I can think of a macro like KMP builds. Maybe the most difficult part is to know the language list before the package build itself...
Mandrake rpm supported partial installation of language components in package according to configured list. So selecting "en ru de" as list of languages resulted in installing only these translations. It was long ago, but I do not think it used subpackages, rather somehow tagged files (may be based on fixed location, like /usr/share/locale/$LANG).
Aha, that's an interesting approach.
But what happens if you enable one more language support on the running system? Would the already installed packages need to be re-installed?
It probably would, but given that changing the list of languages a machine supports shouldn't happen often for most users its probably still a better way forward, especially if yast had a nice gui for updating the supported languages that handled it automatically and zypper had an update-lang option, or even better noticed the change and handled it properly in a zypper up. This would certainly be an interesting project for someone to work on. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Le lundi 24 juin 2019 à 20:23 +0200, Takashi Iwai a écrit :
On Mon, 24 Jun 2019 19:46:32 +0200, Andrei Borzenkov wrote:
24.06.2019 20:21, Takashi Iwai пишет:
Or need to split to subpackages per language?
With a help of rpm macro, it shouldn't be too hard. I can think of a macro like KMP builds. Maybe the most difficult part is to know the language list before the package build itself...
Mandrake rpm supported partial installation of language components in package according to configured list. So selecting "en ru de" as list of languages resulted in installing only these translations. It was long ago, but I do not think it used subpackages, rather somehow tagged files (may be based on fixed location, like /usr/share/locale/$LANG).
Aha, that's an interesting approach.
But what happens if you enable one more language support on the running system? Would the already installed packages need to be re-installed?
Yes, and it was very painful... -- Frederic Crozat Release Manager SUSE Linux Enterprise SUSE
On Mon, 24 Jun 2019 18:38:45 +0200 H.Merijn Brand wrote:
Maybe we just need a new "tool" that cleans up the system of unwanted locales and parts of -lang packages after an installation of update has finished.
BleachBit (run as root). https://software.opensuse.org/package/bleachbit -- WBR Kyrill
* H.Merijn Brand <h.m.brand@xs4all.nl> [06-24-19 11:28]:
On Mon, 24 Jun 2019 17:04:11 +0200, Hans-Peter Jansen <hpj@urpla.net> wrote:
Am Montag, 24. Juni 2019, 15:06:43 CEST schrieb Ignacio Taranto:
On Sat, 22 Jun 2019 at 15:26, Michael Pujos <pujos.michael@gmail.com> wrote:
Does having a lot of packages you do not use slow down the system ? I
No, unless the additional unwanted packages contains services enabled by default (do not know an example about this, but it could be possible). But I'm sure as hell it slows down updates.
Speaking of bloat:
$ du -sh /usr/share/locale/ 811M /usr/share/locale/
Worse
openSUSE Tumbleweed 20190621 $ du -sh /usr/share/locale/ 1.3G /usr/share/locale/
104M /usr/share/locale
And I would love an option to *not* install Thai, Japanese, Chinese and other locales and localized messages that I won't use. Not that I mind on my development laptop, but having this on servers in the cloud rapidly adds to the total space and if the server is known to only need say English and Dutch (or whatever language the server is to support) having all the others is a bit of a burden on the disk space (and thus the backups/snapshots)
FWIW this is not a new problem. I've seen it with e.g. HP-UX that by default came with all supported locales installed (way less than what Linux supports) and I had to remove all those Asian locales before I had enough disk-space to install packages I *did* need.
I do understand the need for all those locales on install, where people choose the language the want to install the distribution in, but a (new) option to exclude (groups of) locales would be welcomed IMHO.
This is a thinkPad X1 (*rev1*), that is severely space constraint...
one of my first actions after a new install, zypper -v rm *-lang -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Registered Linux User #207535 @ http://linuxcounter.net Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 24/06/2019 19.18, Patrick Shanahan wrote:
one of my first actions after a new install, zypper -v rm *-lang
You can only do that if your language is English. And even then, not if the default language of some tool was Russian or Spanish. I would do that, just because :-P -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)
* Carlos E. R. <robin.listas@telefonica.net> [06-24-19 13:28]:
On 24/06/2019 19.18, Patrick Shanahan wrote:
one of my first actions after a new install, zypper -v rm *-lang
You can only do that if your language is English. And even then, not if the default language of some tool was Russian or Spanish. I would do that, just because :-P
one is always free to adjust the regex to their wants/needs. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Registered Linux User #207535 @ http://linuxcounter.net Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 24/06/2019 17.25, H.Merijn Brand wrote:
On Mon, 24 Jun 2019 17:04:11 +0200, Hans-Peter Jansen <hpj@urpla.net> wrote:
...
Speaking of bloat:
$ du -sh /usr/share/locale/ 811M /usr/share/locale/
Worse
openSUSE Tumbleweed 20190621 $ du -sh /usr/share/locale/ 1.3G /usr/share/locale/
...
I do understand the need for all those locales on install, where people choose the language the want to install the distribution in, but a (new) option to exclude (groups of) locales would be welcomed IMHO.
But separate packages for each language would be needed, for each application. This is a lot of packages, a packaging bloat. Only very large applications do this (libreoffice, for example). I can think of ideas. Wild, so pick with a grain of salt ;-) * Somehow making all language directories except those you want "be nil". Nothing can be written there, every write works like writing to /dev/nil. I can not imagine how to accomplish this. Apparmor? bind mounts to nil? or the reverse? * filesystem compression. Those files are basically text, they compress a lot. * A new rpm setting that makes installation skip the actual installation of marked or unmarked parts. * A script triggered somehow (cronjob?) that deletes unwanted languages. * Handle installation of languages outside of the rpm system (send a request per language-application pair and download it; generate the request when each application gets installed). Would need some type of new service and server. Makes mirror download server structure useless. * Create large packages containing "all" (or a big number of) applications in one language, thus download that language only. Could be one set per main pattern. Makes installation of a separate rpm difficult. Bloat of another kind. When a single application changes a single message, you have to update the full pattern-language-rpm. Is any of that work worth it? I don't think so. Me, I would prefer one of the filesystem "tricks" if I had to. -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)
On Monday 2019-06-24 19:22, Carlos E. R. wrote:
* Create large packages containing "all" (or a big number of) applications in one language, thus download that language only. Could be one set per main pattern. Makes installation of a separate rpm difficult. Bloat of another kind. When a single application changes a single message, you have to update the full pattern-language-rpm.
We used to have that in 13.2. bundle-lang-common-{ar,dk,en}... -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 22/06/2019 20.26, Michael Pujos wrote:
On 22/06/2019 20:02, Ignacio Taranto wrote:
If you have a laptop with a small disk, let's say 128 or 256 GB, space *will* matter. Having a bunch of things you don't use/need is inefficient.
If you are so low on storage to care about that, you will probably not use btrfs and snapshots, so we can remove that from the discussion.
But the tools are installed by default. I had them removed and an update today put them back. I have not yet studied why. And yast/zypper starts them on every update. There is a report about zypper dup stalling for minutes, some snapshot or btrfs operation (I forgot which), despite there not being any btrfs partition (there is a bugzilla). ...
Does having a lot of packages you do not use slow down the system ? I don't think so as it is not going to affect startup times significantly. Though it can be painful if you have a slow internet connection.
It slows updates; not only the download, but also the calculation of them. The default uses delta rpms, with a longish CPU time.
That being said, it would still be good to have a mode of operation of the distro that can keep things fairly minimal without the fear of breaking stuff.
- -- Cheers / Saludos, Carlos E. R. (from oS Leap 15.0 x86_64 (Minas Tirith)) -----BEGIN PGP SIGNATURE----- iHUEAREIAB0WIQQt/vKEw5659AgM/X2NrxRtxRYzXAUCXRDXPAAKCRCNrxRtxRYz XPTQAPoCmARVhMP8aBWgVeRQbFitaWNKMkM9nxJMSqD8a3Op7AD9EIFJNL2Jz4qa Wceny3mvpVPmUw4kB6rJCFbIjoCiEpY= =/Nov -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 22/06/2019 20.26, Michael Pujos wrote:
On 22/06/2019 20:02, Ignacio Taranto wrote:
If you have a laptop with a small disk, let's say 128 or 256 GB, space *will* matter. Having a bunch of things you don't use/need is inefficient.
If you are so low on storage to care about that, you will probably not use btrfs and snapshots, so we can remove that from the discussion.
But the tools are installed by default. I had them removed and an update today put them back. I have not yet studied why.
They are recommended from another package that is installed. Zypper will pull back recommended packages on updates. If you do not want them you can lock them "zypper al <package>".
And yast/zypper starts them on every update. There is a report about zypper dup stalling for minutes, some snapshot or btrfs operation (I forgot which), despite there not being any btrfs partition (there is a bugzilla).
...
Does having a lot of packages you do not use slow down the system ? I don't think so as it is not going to affect startup times significantly. Though it can be painful if you have a slow internet connection.
It slows updates; not only the download, but also the calculation of them. The default uses delta rpms, with a longish CPU time.
That being said, it would still be good to have a mode of operation of the distro that can keep things fairly minimal without the fear of breaking stuff.
-- Benjamin Zeller <bzeller@suse.de> Systems Programmer SUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nürnberg Tel: +49-911-74053-0; Fax: +49-911-7417755; https://www.suse.com/ SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
On 24/06/2019 16.15, Benjamin Zeller wrote:
On 22/06/2019 20.26, Michael Pujos wrote:
On 22/06/2019 20:02, Ignacio Taranto wrote:
If you have a laptop with a small disk, let's say 128 or 256 GB, space *will* matter. Having a bunch of things you don't use/need is inefficient.
If you are so low on storage to care about that, you will probably not use btrfs and snapshots, so we can remove that from the discussion.
But the tools are installed by default. I had them removed and an update today put them back. I have not yet studied why.
They are recommended from another package that is installed. Zypper will pull back recommended packages on updates. If you do not want them you can lock them "zypper al <package>".
Yes, I know. As I said, I have not investigated yet. If. :-) -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)
On pon, cze 24, 2019 at 3:59 PM, Carlos E. R. <robin.listas@telefonica.net> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 22/06/2019 20.26, Michael Pujos wrote:
On 22/06/2019 20:02, Ignacio Taranto wrote:
If you have a laptop with a small disk, let's say 128 or 256 GB, space *will* matter. Having a bunch of things you don't use/need is inefficient.
If you are so low on storage to care about that, you will probably not use btrfs and snapshots, so we can remove that from the discussion.
But the tools are installed by default. I had them removed and an update today put them back. I have not yet studied why. And yast/zypper starts them on every update. There is a report about zypper dup stalling for minutes, some snapshot or btrfs operation (I forgot which), despite there not being any btrfs partition (there is a bugzilla).
...
In essence, that's caused by the design of zypp itself. Instead of using a more brain dead system of keeping track of packages that user actually wants installed or removed, zypp tries to fill the needs of packages (which is not very clever if the packages are recommended and not required). In case of dnf, the info about which packages were installed "on purpose" by user, and which were installed as a dependency is kept in a database, so any change of the deps affects packages that are removed or installed to the system. In case of zypp, it treats everything as installed "on purpose", so in many cases even adding -u to zypper rm will not remove all the dependencies. Similar thing is also done by emerge (in a plaintext file though) and a few other simple package managers, because it leverages users over "recommendations", which should never be required or automatically reinstalled as they currently are.
Does having a lot of packages you do not use slow down the system ? I don't think so as it is not going to affect startup times significantly. Though it can be painful if you have a slow internet connection.
It slows updates; not only the download, but also the calculation of them. The default uses delta rpms, with a longish CPU time.
And tumbleweed users suffer even more, no deltarpm, just a whole bunch of gigabyte size updates a week ;)
That being said, it would still be good to have a mode of operation of the distro that can keep things fairly minimal without the fear of breaking stuff.
LCP [Stasiek] https://lcp.world -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 24/06/2019 16.26, Stasiek Michalski wrote:
On pon, cze 24, 2019 at 3:59 PM, Carlos E. R. <> wrote:
On 22/06/2019 20.26, Michael Pujos wrote:
On 22/06/2019 20:02, Ignacio Taranto wrote:
If you have a laptop with a small disk, let's say 128 or 256 GB, space *will* matter. Having a bunch of things you don't use/need is inefficient.
If you are so low on storage to care about that, you will probably not use btrfs and snapshots, so we can remove that from the discussion.
But the tools are installed by default. I had them removed and an update today put them back. I have not yet studied why. And yast/zypper starts them on every update. There is a report about zypper dup stalling for minutes, some snapshot or btrfs operation (I forgot which), despite there not being any btrfs partition (there is a bugzilla).
...
In essence, that's caused by the design of zypp itself. Instead of using a more brain dead system of keeping track of packages that user actually wants installed or removed, zypp tries to fill the needs of packages (which is not very clever if the packages are recommended and not required). In case of dnf, the info about which packages were installed "on purpose" by user, and which were installed as a dependency is kept in a database, so any change of the deps affects packages that are removed or installed to the system. In case of zypp, it treats everything as installed "on purpose", so in many cases even adding -u to zypper rm will not remove all the dependencies. Similar thing is also done by emerge (in a plaintext file though) and a few other simple package managers, because it leverages users over "recommendations", which should never be required or automatically reinstalled as they currently are.
Did you know that YaST did have a feature that kept track of what was removed by the admin, and did not install those automatically? ;-) The feature had to be removed years ago because it backfired somehow. I lost track of an email or link that said this, so you'll have to take my word that it existed :-)
Does having a lot of packages you do not use slow down the system ? I don't think so as it is not going to affect startup times significantly. Though it can be painful if you have a slow internet connection.
It slows updates; not only the download, but also the calculation of them. The default uses delta rpms, with a longish CPU time.
And tumbleweed users suffer even more, no deltarpm, just a whole bunch of gigabyte size updates a week ;)
Yep, you do :-p -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)
On Sat, 22 Jun 2019 15:02:47 -0300 Ignacio Taranto <itaranto7@gmail.com> wrote:
On Sat, 22 Jun 2019 at 11:04, Michael Pujos <pujos.michael@gmail.com> wrote:
In my opinion, openSUSE is not the distro for users wanting their software taking the minimal disk space possible with everything not needed perceived as "bloat" that has to be removed. It's just not a minimal distro.
You can try if you wish blocking packages and stuff at the expense of it taking a lot of your time and the possiblity of breaking stuff for what...saving 1 or 2GB of disk space with the fuzzy feeling of duty achieved ? Or you can just relax and don't care an let the system do its stuff.
The only case where I locked packages is texlive as > 1000 packages for it is a bit too much, or if I install manually a program that conflicts with a package.
That is not to say some improvement can be made in term of dependencies. But I quite like that each installed package is full featured.
If you have a laptop with a small disk, let's say 128 or 256 GB, space *will* matter. Having a bunch of things you don't use/need is inefficient.
I would like to point out that ARM devices commonly come with 32GB card or emmc storage (as the largest option). If the card is removable you can get a 64GB or 128GB one but these tend to be relatively expensive and support for these larger sizes is not well tested. On a device with 16 or 32GB storage saving 2GB is quite noticeable. Thanks Michal -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 22.06.19 um 16:04 schrieb Michael Pujos:
... The only case where I locked packages is texlive as > 1000 packages for it is a bit too much, ...
Ah, this reminds me of a surprise when texlive did that on my computer and wanted about 2GB additional diskspace, and I don't use TeX So I blocked it. It is not just the never used programm which pulls others, it is also the unnecessary updates for those which waste time. Peter -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Saturday 2019-06-22 16:04, Michael Pujos wrote:
In my opinion, openSUSE is not the distro for users wanting their software taking the minimal disk space possible
That was never an advertised goal to begin with. For that, you would probably want something like Gentoo/LFS where things are left out at compilation time already. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 22/06/2019 23:34, Michael Pujos wrote:
In my opinion, openSUSE is not the distro for users wanting their software taking the minimal disk space possible with everything not needed perceived as "bloat" that has to be removed. It's just not a minimal distro.
This is probably true, at the same time there is a bunch of stuff we have for "historical" reasons that we can improve for everyone and if people are willing to work on that its great. Its not possible for binary distro's to be truly minimal but we can certainly make openSUSE better then it is now. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (24)
-
Andreas Schwab -
Andrei Borzenkov -
Benjamin Zeller -
Bernhard M. Wiedemann -
Carlos E. R. -
Felix Miata -
Frederic Crozat -
H.Merijn Brand -
Hans-Peter Jansen -
Herbert Graeber -
Ignacio Taranto -
Jan Engelhardt -
Kyrill Detinov -
Luca Beltrame -
Maurizio Galli (MauG) -
Michael Pujos -
Michael Ströder -
Michal Suchánek -
Patrick Shanahan -
Peter McD -
Simon Lees -
Stasiek Michalski -
Takashi Iwai -
Thorsten Kukuk