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 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 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

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

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 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 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

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 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

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

Am Montag, 24. Juni 2019, 15:06:43 CEST schrieb Ignacio Taranto:

On Sat, 22 Jun 2019 at 15:26, Michael Pujos 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:25:37 +0200 "H.Merijn Brand" wrote:

On Mon, 24 Jun 2019 17:04:11 +0200, Hans-Peter Jansen wrote:

...

Am Montag, 24. Juni 2019, 15:06:43 CEST schrieb Ignacio Taranto:

...

On Sat, 22 Jun 2019 at 15:26, Michael Pujos 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 Mon, 24 Jun 2019 17:50:19 +0200 Andreas Schwab wrote:

On Jun 24 2019, Michal Suchánek 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:38:45 +0200, H.Merijn Brand wrote:

On Mon, 24 Jun 2019 18:13:17 +0200, Michal Suchánek wrote:

...

On Mon, 24 Jun 2019 17:50:19 +0200 Andreas Schwab wrote:

...

On Jun 24 2019, Michal Suchánek 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

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

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

* H.Merijn Brand [06-24-19 11:28]:

On Mon, 24 Jun 2019 17:04:11 +0200, Hans-Peter Jansen wrote:

...

Am Montag, 24. Juni 2019, 15:06:43 CEST schrieb Ignacio Taranto:

...

On Sat, 22 Jun 2019 at 15:26, Michael Pujos 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

* Carlos E. R. [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 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

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 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 pon, cze 24, 2019 at 3:59 PM, Carlos E. R. 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 Sat, 22 Jun 2019 15:02:47 -0300 Ignacio Taranto wrote:

On Sat, 22 Jun 2019 at 11:04, 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.

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

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